[M3devel] cm3 pthread problem?... another one?

[Tony Hosking]

Argh!  That signal isn't even documented as being returned by  
pthread_kill on Linux (at least in my man pages).

So the solution appears to be to replace:

           WITH r = Upthread.kill(act.handle, SIG_SUSPEND) DO
             <*ASSERT r=0*>
           END;

with:

	LOOP
	  WITH r = Upthread.kill(act.handle, SIG_SUSPEND) DO
	    IF r = 0 THEN EXIT; END;
	    IF r # Uerror.EAGAIN THEN <*ASSERT FALSE*>; END;
	    (* try it again *)
	  END;
	END;

What do you think?   I wonder how many other places I should be  
checking for EAGAIN?

On Apr 22, 2007, at 4:58 PM, Dragiša Durić wrote:

> On Sun, 2007-04-22 at 15:47 -0400, Tony Hosking wrote:
>> It is a pthreads call that is failing:
>>
>>            WITH r = Upthread.kill(act.handle, SIG_SUSPEND) DO
>>              <*ASSERT r=0*>
>>            END;
>>
>> I'm guessing we are in a race with a thread that is in the middle of
>> dying (i.e., the error code, "r", is "ESRCH: thread is an invalid
>> thread ID").  Can you confirm that is the error?
>
> No :). It's 11 - EAGAIN, IIRC. Lot's of signals are sent there, and it
> kicked some signal dequeuing limit, or something like.
>
>> As for why it is happening I don't know, since the thread handle is
>> only ever accessed while activeMu is locked, which enforces atomicity
>> of the thread's presence in the ring of live threads along with its
>> handle being valid:
>>
>>      WITH r = Upthread.mutex_lock(activeMu) DO <*ASSERT r=0*> END;
>>        IF allThreads = me THEN allThreads := me.next; END;
>>        me.next.prev := me.prev;
>>        me.prev.next := me.next;
>>        me.next := NIL;
>>        me.prev := NIL;
>>        WITH r = Upthread.detach(me.handle) DO <*ASSERT r=0*> END;
>>      WITH r = Upthread.mutex_unlock(activeMu) DO <*ASSERT r=0*> END;
>>
>> I wonder if this is a system limit on the number of threads or some
>> such (but then why would the pthread_create call not return an
>> error?)  Can you diagnose further?
>
>   Limit is not, it's sure. I am running test in parallel with mine
> implementation + pm3, and it works without a flaw, 10000 rounds, 4000
> threads each. I am using some realtime signal for suspend magic,
> though... Don't remember right now, but I think there is something
> special about this queuing of realtime and non-realtime signals...
>
>>
>> On Apr 22, 2007, at 5:12 AM, Dragiša Durić wrote:
>>
>>>   After upping it a bit, with stack limit set to 64k and 4000
>>> threads in
>>> each loop... Is not happening at same place every run, but most of
>>> runs
>>> - it happens.
>>>
>>> Forking 4000 threads... (1)
>>> Forked.
>>> ,:
>>>
>>> ***
>>> *** runtime error:
>>> ***    <*ASSERT*> failed.
>>> ***    file "../src/thread/PTHREAD/ThreadPThread.m3", line 1083
>>> ***
>>>
>>>
>>> On Sat, 2007-04-21 at 10:48 -0400, Tony Hosking wrote:
>>>> I have fixed this bug and checked in the fix to CVS (why are we not
>>>> seeing the commit messages again?).  It did turn out to be a  
>>>> deadlock
>>>> issue in the handshake between allocating threads and the GC.  Your
>>>> sample program now runs with no problems on my dual-core Intel Mac.
>>>> Please let me know if you have any other threading difficulties.
>>>>
>>>> Regards,
>>>>
>>>> Tony
>>>>
>>>> On Apr 20, 2007, at 8:21 AM, Dragiša Durić wrote:
>>>>
>>>>> Attached program won't run under freshly built cm3 @ Fedora  
>>>>> Core 6.
>>>>> Compiles, runs... and stucks...
>>>>>
>>>>> It works flawlessly with user-level threads and also with mine
>>>>> implementation of NPTL for pm3. I've done it for 4000 threads per
>>>>> 10000
>>>>> passess, and this version I am attaching, and trying without
>>>>> success on
>>>>> CM3 is 40 threads...
>>>>>
>>>>> Of course, before I run it, I am ulimiting stack size to 64kB or
>>>>> similar.. It fits.
>>>>>
>>>>> dd
>>>>> -- 
>>>>> Dragiša Durić <dragisha at m3w.org>
>>>>>
>>>>> _______________________________________________
>>>>> M3devel mailing list
>>>>> M3devel at elegosoft.com
>>>>> https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel
>>>>
>>> -- 
>>> Dragiša Durić <dragisha at m3w.org>
>>
> -- 
> Dragiša Durić <dragisha at m3w.org>