[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