This is the mail archive of the kawa@sourceware.org mailing list for the Kawa project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Thread local readtables


* Per Bothner [2008-03-20 17:49+0100] writes:

> Helmut Eller wrote:
>> I'd like to use different readtables in different threads.
>> Is there a recommended way to do that?
>
> As far as I know, it should just work.
>
>> I tried gnu.kawa.lispexpr.ReadTable:setCurrent, but that seems to set
>> the global binding.
>
> No, it sets the thread-local binding: It calls current.set(rt),
> where current is a "ThreadLocation".

I don't understand how ThreadLocations work.  But I tried this:

shell> cat rt.scm 

(define (foo)
  (call-with-input-string 
   "foo:bar" (lambda (p) 
               (format #t "~a\n" (read p))
               (force-output))))

(future (do () (#f) (foo) (sleep 1)))

(future (begin 
          (sleep 5) 
          (gnu.kawa.lispexpr.ReadTable:setCurrent
           (gnu.kawa.lispexpr.ReadTable:createInitial))))
shell> kawa -f rt.scm 
($lookup$ foo (quasiquote bar))
($lookup$ foo (quasiquote bar))
($lookup$ foo (quasiquote bar))
($lookup$ foo (quasiquote bar))
($lookup$ foo (quasiquote bar))
foo:bar
foo:bar
foo:bar
foo:bar
foo:bar

[Exit 130 (SIGINT)]
/tmp > 

Which made me conclude that the location is shared between the threads.
Maybe this has something to do with the way FUTURE works.

>
> We could easily generalize (current-readtable) (see
> gnu/kawa/slib/readtable.scm) to a "parameter", if that
> would be useful:

Yes, that would be useful (if it works with futures).

>
> (define-alias-parameter current-readtable <read-table>
>   (static-field <readtable> 'current))
>
> using define-alias-parameter as defined in ports.scm.

If I try the above I get:
Argument #2 (gnu.kawa.lispexpr.ReadTable@9f3e95) to 
'gnu.mapping.LocationProc.makeNamed(gnu.mapping.Symbol,gnu.mapping.Location)'
has wrong type (gnu.kawa.lispexpr.ReadTable) (expected: gnu.mapping.Location)

For me (static-field <readtable> 'current) returns actually
gnu.kawa.lispexpr.ReadTable@9f3e95 and not a Location.  

Maybe because the "current" in field ReadTable.java isn't public but the
"getCurrent" method is public?

>
> OTOH it seems like incremental readtable modification
> is more useful.

I use a Common Lisp/Emacs Lisp readtable (with the usual :keyword
syntax) in one thread and the Scheme readtable in another thread.

>
>> It would nice if READ would take the readtable as
>> (optional) argument, instead of repeatedly calling
>> gnu.kawa.lispexpr.ReadTable:getCurrent.
>
> We do pass the ReadTable as a parameter to some of the internal
> routines, though I'm sure we can do better.  Passing it to the
> Scheme read routine is trickier.  Whether it's worthwhile
> depends on whether it uses significant time in big picture.
> Does it?

Probably not.  It just seemed to me that READ always creates a fresh
LispReader object and that it would be the easiest to make the readtable
an instance variable of the LispReader.  But the comments at the
beginning LispReader.java make it sound like LispReader will go a away
soon and passing the readtable to READ would be the next easiest for me.

Helmut.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]