[Openmcl-devel] Asynchronous callback made from real-time thread

[Gary Byers]

On Sat, 31 May 2003, Letz Stephane wrote:


>
> I guess the simpler solution right now if to implement a blocking
> call for incoming Midi events and use a Lisp created thread to read
> them.

That sounds like it'd be generally useful.

>
>
> >
> >Getting foreign threads to be treated like processes (making the
> >value of *CURRENT-PROCESS* meaningful, having lisp PROCESS objects
> >for them, having them show up in (ALL-PROCESSES) and :PROC, etc)
> >is harder than just allocating a TCR would be.  If your event handler
> >callback can refrain from thinking that it's running in a lisp process,
> >there isn't much new code involved in creating a TCR; getting the other
> >stuff to work would probably require some ABI changes.
> >
>
> Do you plan to implement the get_tcr() stuff and all what would be
> needed to implement the "complex" solution at some point?

I've been trying to bootstrap some CLOS changes for about 10 days
now.  I thought that it'd take about 4 days, so you may want to take
my estimates of what's easy and what's hard with a grain of salt.

get_tcr() itself is fairly easy: it's pretty much the same code that's
run when a lisp-created thread starts up.

When a lisp-created thread starts up, it creates a PROCESS object for
itself, binds *CURRENT-PROCESS* to that process object and binds several
other special variables to reasonable values, calls the user-specified
function, and then returns to code which removes the process from
(ALL-PROCESSES) and returns to some code in the lisp kernel which
basically causes the thread to exit.  When a thread exits (normally
or otherwise), a cleanup handler deallocates its TCR (and the associated
lisp stacks) and undoes other things that were done when it was created.

If we just implement get_tcr() without trying to make all of the other
stuff work, the foreign thread will be able to run a callback.  That
callback will run in a somewhat strange dynamic environmemt: the value
of *CURRENT-PROCESS* will be wrong, several other special variables
will have values that aren't thread-specific (and may in fact be shared
with the initial thread.)  This may or may not be important in your
case or in other cases where people need to make callbacks from foreign
threads.

One thing that -will- be correct in that environment is the value
returned by the intrinsic function CCL::%CURRENT-TCR.  That value is
used to identify lock ownership, so things like WITH-LOCK-GRABBED will
work; other things that may depend on *CURRENT-PROCESS* (for instance)
having a sane value would not work.

I thought about this some more, and the hard parts (making/deleting
a process object and providing the foreign thread with private
bindings of the same variables that lisp threads bind by default)
may not be quite as hard as I'd thought at first.  It will require
some ABI changes, and I want to try to get the CLOS changes stable
and make binaries for them available before introducing other low-level
changes.

I don't know much about MIDI, but I'm sure that many people would be
interested in it (both for its own sake and as an example of Why
Native Threads Are A Good Thing.)

The best answer I can give is "soon", but you may want to multiply
that by 2 or 3 ...

>
> Thanks
>
> Stephane
>
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> http://clozure.com/cgi-bin/mailman/listinfo/openmcl-devel
>
>

_______________________________________________
Openmcl-devel mailing list
Openmcl-devel at clozure.com
http://clozure.com/cgi-bin/mailman/listinfo/openmcl-devel