[Ecls-list] multi-threaded C++ app

[Dean O'Connor]

Juanjo

I can't thank you enough for that detailed answer !!! Nice one.

I'll have to absorb the ramifications of what you are saying :)

But I have just done an update from CVS 
:pserver:anonymous at cvs.sourceforge.net:/cvsroot/ecls
and I don't find a mention of those functions anywhere ???

Cheers
Dean.

Juan Jose Garcia Ripoll wrote:

>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
>
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by:
>Power Architecture Resource Center: Free content, downloads, discussions,
>and more. http://solutions.newsforge.com/ibmarch.tmpl
>_______________________________________________
>Ecls-list mailing list
>Ecls-list at lists.sourceforge.net
>https://lists.sourceforge.net/lists/listinfo/ecls-list
>  
>