[Openmcl-devel] using pthreads from openmcl
Gary Byers
gb at clozure.com
Wed Mar 26 10:10:47 PST 2003
On Wed, 26 Mar 2003, Taoufik Dachraoui wrote:
> Hi,
>
> I tried process-run-function but the process blocks at XNextEvent, and this is not what I am looking for.
>
> So I decided to use pthreads from openmcl. I did the following:
The lisp runtime system and GC (in 0.13.x) assume a cooperatively
scheduled threading model. Trying to run lisp code on threads
(on stacks ...) that are created "behind its back" will fail in
a variety of unpleasant and unpredictable ways.
>
> ? (setq y nil)
> ? (defcallback xmain () (setq y t))
> ? (setq thread (ccl::make-record :pthread_t))
> ? (#_pthread_create thread (%null-ptr) xmain (%null-ptr))
> 0
> ? Trace/BPT trap
> >
>
> Why do I get the Trace/BPT trap?
>
There could be any number of reasons.
OpenMCL's lisp threads each use multiple stacks (3 of them, to
be precise.) #_pthread_create will create one of these; lisp
code running on such a thread will wind up "sharing" some other
stacks that belong to the currently scheduled cooperative thread.
I wouldn't want to guess what happens next ...
> The Trace/BPT trap do not occur all the times, sometimes the
> callback function is called by the pthread and sets y to t.
> The idea is to define a callback xmain function that uses xlib
> functions. xmain will use XNextEvent (a blocking function).
> The reason I am not using CLX is that I feel that I will learn more
> by trying from scratch to implement a framework for developing X
> Window programs using openmcl, this way I feel that I am learning
> more about common lisp and openmcl in particular.
You've learned (the hard way) about some of the limitations of
cooperatively scheduled lisp threads.
OpenMCL 0.14 uses "native" (POSIX) threads; it's not quite
feature-complete and probably not yet stable enough for production
use, but it's (in at least some sense) usable. (It needs to be better
documented.) It's not currently possible to call #_pthread_create
directly and then run lisp code on the resulting thread, but it might
be in the near future (there are certainly cases where this is a
desirable thing to do.) PROCESS-RUN-FUNCTION and related functions
call #_pthread_create internally (and set up some additional lisp
infrastructure); the resulting threads can call blocking functions
like XNextEvent without preventing other threads from running.
CLX works around the blocking issue: it communicates with the X server
via a socket-based stream and uses LISTEN on that stream to avoid
blocking when no input is available.
_______________________________________________
Openmcl-devel mailing list
Openmcl-devel at clozure.com
http://clozure.com/cgi-bin/mailman/listinfo/openmcl-devel
More information about the Openmcl-devel
mailing list