[M3devel] 5.8.6 LINUXLIBC6 breakage, kernel 2.6.23, glibc-2.6-4
hosking at cs.purdue.edu
Mon Apr 18 19:05:46 CEST 2011
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...
> 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.
> 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?
More information about the M3devel