[Ecls-list] Multithreaded code

[Valery Syssik]

Juanjo!
Thanks you very match to complete description of integration
MT run-time's belongs to different languages (Lisp and C for in our case).

You explain problems:
1. allocate per-thread resources & separating assess to them.
2. sharing some resources & serialize access to them.

I am rather familiar with threading in C/C++ applications,
and freshman in Lisp threading.

For example I look at Cormanlisp (if you interested I may covert Power Point presentation
into PDF format):
-----------------------------------------------------------------------
http://www.cormanlisp.com/Multi-threaded%20Lisp.ppt
http://www.google.ru/search?q=corman+lisp+threads

Thread Implementation Issues
  Special variables
  Heap access
  Garbage collection
  Foreign calls and callbacks
  Code generation
  Debugging
  Lisp Image saving and loading
  Foreign Threads
Dynamic Bindings in Corman Lisp
 Top level bindings should be shared between threads.
 Dynamic  bindings (via LET, etc.) should only apply to the thread the
 created the binding.
 Is  there  ever  a reason for dynamic bindings to be visible to other
 threads? (I haven’t found one.)
-----------------------------------------------------------------------

I am interested in ECL internals:
i.e. formal specification about:

 - objects are shared and serialized via ECL internals semaphores
   (GC, Code generation, global symbol tables)
 - objects are shared and serialized via manual calls of sync
   primitives
   (all composite data: list's, arrays, structures, ...)
 - thread safety of Lisp system calls in ECL (reentrant function).
 - List of sync. primitives supported in ECL (mutex, condition variables)
 - C run-time version used in ECL library.



> Well, you have to understand one thing, which is that in a lisp 
> implementation, each thread needs to have some resources
<...>

> (mp::process-run-function #'entry-point "thread is running")

> I agree that sometimes you want to create the thread in the C world.
Yes, of course.
Even if using pre-threaded model (thread pool).
> Well, in that case one should import the thread into the lisp world. The
> code for that is not yet done, but I can create easily a C function 
> called ecl_import_thread()  which creates the appropiate resources for
> running code in the given thread.
It should be great.
<...>

P.S. sorry for my poor English.

Valery.