[Ecls-list] multi-threaded C++ app
Juan Jose Garcia Ripoll
lisp at arrakis.es
Wed Oct 12 02:25:11 UTC 2005
Hi,
sorry for the lack of quoting but I thought it would be easier if I
begin from scratch.
The issue is how well can a multithreaded application collaborate with a
multithreaded version of Lisp. The problem is as follows. A
multithreaded lisp application needs to keep a number of resources per
thread. We are talking about an interpreter stack, variable bindings,
block/tagbody/catch frames, etc. All this data is stored in a
thread-local structure called "cl_env" (src/h/external.h).
Let us imagine for a second that you have a multithreaded application
that wants to call lisp from each thread. There are over 1200 C
functions in ECL that it can potentially call. All of them will need
cl_env to have been properly initialized. It would be a waste of
resources to include check points in each of these functions to ensure
that the calling thread has been registered with the lisp world.
In CVS I have coded two functions which should solve somehow the
problem:
void ecl_import_current_thread(cl_object name, cl_object binding);
void ecl_release_current_thread(void);
The first one imports the _current_ thread into the lisp world by
creating the appropiate cl_env structure. The second one releases the
current thread by cleaning up this structure.
You have to call ecl_import_thread() before invoking any lisp code in a
thread that has not been created with lisp and which has not called
cl_boot(). You should call ecl_release_thread() before this thread
exits.
There are however important left issues. For instance, once you register
your thread with the lisp world, it may be interrupted by other lisp
threads. While these interrupts are gracefully handled in the lisp
enviroment, this might not be what your application likes.
Regards,
Juanjo
More information about the ecl-devel
mailing list