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

[Tony Hosking]

On Apr 18, 2011, at 12:42 PM, Mika Nystrom wrote:

> 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.)

pthread_atfork should not be needed under user threads.

> 
> 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?

Not so much bugs in GC as bugs in thread interactions with GC perhaps.  The GC itself has been stable for a long time.

>  The user threads m3core disables
> the garbage collector at different points from where the pthreads m3core
> does, no?