Vladimir, Sam,
> >> I plan to create the thread2 branch after I switch to gnulib
> >> threadlib/lock/cond to get solaris and win32 "for free".
As I wrote to Sam on 2008-08-17 in private mail: For clisp, I would attempt
to stay with the POSIX threads API, rather than using gnulib's wrapper
modules. Why?
- gnulib's modules are targeted at the average application programmer,
whereas clisp is more at the system programming level.
- The POSIX threads API is better documented than gnulib's wrapper modules.
- For the platforms that are interesting for clisp (Linux, *BSD, MacOS X,
Solaris, Windows), POSIX threads are either well supported or emulated
using the pthreads-win32 package.
- You want additionally spinlocks, which POSIX has
(<http://www.opengroup.org/susv3/functions/pthread_spin_init.html>) but
gnulib does not yet have.
The only advantages of gnulib's modules in this case are
- A more systematic naming convention of the functions,
- Portability to older OSes, like Solaris 7, Tru64, and similar.
Like with the execute/pipe modules and posix_spawn, also here with the threads
I think the way to go is to separate the gnulib functionality into
1. an emulation the POSIX API,
2. a convenience API layer on top of the POSIX API.
> would it be possible to make gnulib cond allocate on stack?
You mean, the gl_cond_t variable should be allocated on the stack? It is
already possible. But note that the extent of such a variable must encompass
the lifetime of the threads that use it; that's why it is usually allocated
with indefinite extent.
> would it be possible to use fast clisp spinlocks in gnulib lock?
That code is CPU dependent and relies on GCC's inline asms. It is certainly
better to use pthread_spin_* where available (and emulate them where not
available - but that might be hard if not assuming GCC).
Regarding clisp's xthread.d: The first thing I would do now is to ditch the
conditional code for POSIXOLD_THREADS, SOLARIS_THREADS, C_THREADS. You don't
need these APIs any more. And with pthreads-win32 you don't need WIN32_THREADS
either.
> > The xmutex_t should be recursive (for consistency - critical section
> > on Win32 are recursive - and gnulib uses them as well).
Both POSIX and gnulib offer normal and recursive locks. You just choose
which one you need.
> > The cond implementation in gnulib uses malloc() while the current
> > clisp implementation uses the stack.
There is a comment in gnulib/lib/glthread/cond.c that explains why here
malloc() is better than stack allocation.
> > I just looked on the gnulib and do not see "realy fast" spinlocks
> > (may be I am wrong - have not looked too hard). In the current clisp
> > spinlocks are inlined assembly instructions. Every heap allocation is
> > guarded with a spinlock - so any overhead may cause significant
> > decrease in performance.
Do you want to help implementing fast pthread_spin_* replacement functions
in gnulib? This would be a benefit for both clisp and gnulib:
- clisp could use the pthread_spin_* functions from the OS when they are
good enough or when the CPU is exotic,
- gnulib would have fast pthread_spin_* functions.
Bruno
