[M3devel] 5.8.6 LINUXLIBC6 breakage, kernel 2.6.23, glibc-2.6-4

[Mika Nystrom]

Tony Hosking writes:
>Well, that is reassuring news.
>If the problems are isolated to threading then they can be resolved easily.
>
>On Apr 7, 2011, at 3:02 PM, Mika Nystrom wrote:
>
>> 
>> Remember that for mission-critical applications there's always user
>> threading..  I find that the system (up to and including the CVS head
>> and on both amd64 and i386 flavors of Linux as well as every other OS I
>> have tried) is very very stable with user threading.  I'm eager to use
>> pthreads again of course, for all sorts of reasons...
>> 
>>    Mika


Actually I'm afraid I have to take this back.  After digging a bit here,
I *think* user threads are OK with the proviso that one not link with
-pthread.  But I'm not sure.

Unfortunately, user threads require -pthread on most systems because
of pthread_atfork.  I asked Jay what pthread_atfork is used for *under
user threads* but he never answered my question.  I had understood
that pthread_atfork is used in the pthreads implementation to simulate
the old behavior of user threads and that it wasn't needed under user
threads...  I'm also not sure how to change RTProcessC.c so that it
picks up pthread_atfork exactly when user threading has been specified.
(Programs won't link with pthread_atfork in them without -pthread.)

In any case I am pretty sure that linking with -pthread picks up versions
of malloc and free that really don't like being called reentrantly---and
by "don't like" I mean the worst kind of crash: the application locks up
hard in some sort of spin lock.  A segfault would be preferable by far.
And m3core has a lot of unprotected calls to free in it.

There may be some really nasty bugs here.  They are nasty because they
kill reliability, kill liveness, and can't really be programmed around
because they are in such a vital subsystem (namely threading).  I would
go back to PM3 if I could but I think I'm stuck with CM3 now.  

     Mika

P.S. as far as the pthreads bugs go I think it's still a possibility the 
bugs are in the garbage collector?  The user threads m3core disables
the garbage collector at different points from where the pthreads m3core
does, no?