On Sunday 15 July 2007 1:45:20 pm Benoit Chesneau wrote: > I tested on cvs version with i386. I have no warning yet. Juste one > thing why don't you use -DGC_OPENBSD_THREADS flag to enable use of > pthread. It worked.
Defining GC_OPENBSD_THREADS is not sufficient for enabling thread support in boehm. Use the configure arg --enable-threads=pthreads test thread support in boehm. Try a make regress and you will see the current show stopper. > > Find enclosed last version of boehm-gc 6.8 I was > worked before new port for 7.0 was published. It contain more patching > about it. I didn't have time yet to put them in 7.0 Hope it could > help. I reviewed the patches in 6.8. I suspect thread support was not fully enabled when you tested it. There's nothing in the patches to get past the stop world deadlocks that happen when thread support is properly enabled. Other patches are incorrect such as the SIGRTMIN/MAX bit. Userland pthreads has limitations. Conceptually it sits between the program and the kernel and simulates actual threads. It does this by doing things like converting all file descriptors to non-blocking and managing all blocking operations. For signals it manages signal masks, intercepts signal delivery and manages the delivery of the singals to the threads. There are cases where pthreads defers delivery of a signal to a thread because interrupting the current operation would be bad. boehm uses signals to interrupt threads, grab the current stack pointer and put them to sleep in the signal handler using sigsupend(). So when a thread is in a state where the signal is deferred the process deadlocks. There's no good work-around for this problem. Thread support for boehm-gc will need to wait for rthreads (real kernel supported threads). One last thing to note. If you attempt to use non-threaded boehm-gc in a threaded program, expect failures ranging from immediate deadlock to crashes since only the main thread will be garbage collected without locking. -Kurt
