[M3devel] Status of threads for RC4?

[Olaf Wagner]

Quoting Tony Hosking <hosking at cs.purdue.edu>:

> The gross fix is to have threads in blocking pthread calls to post
> their blocked status on entry.  The GC stop-world code can simply
> notice they are blocked and not try to signal them, but just set their
> status to stopping.  When the blocked thread returns from the blocking
> call it can notice the stopping state and transition to stopped,
> waiting on the stop-world semaphore.  This appears to be what the
> Kaffe VM folks do.  The unfortunate thing is that this is *totally
> unnecessary* on every other platform except OpenBSD, as far as I  know.
>  We do not want to add cruft to the thread primitives just to  support
> a broken user-level threads system.  Better just to revert  OpenBSD to
> our own user-level ThreadPosix implementation until OpenBSD  wakes up
> to the real world of SMP and multicore.

Yes. We should not introduce unnecessary workarounds for broken
platform libraries. If user-level threads work, that should be fine.

Olaf

> On 21 Oct 2009, at 09:38, Tony Hosking wrote:
>
>> Precisely.  The problem is that the signal mechanism to stop thread  
>>   for GC is not working.  This is a bogosity of the OpenBSD   
>> user-level  threads implementation.  Either we configure OpenBSD to  
>>  use  ThreadPosix instead of ThreadPThread or we switch to rthreads.
>>
>> On 21 Oct 2009, at 05:06, Jay K wrote:
>>
>>> Interesting -- Juno on Win32 also doesn't hang with @M3nogc, with   
>>>  over 200 runs (using @M3no-trestle-await-delete).
>>>
>>> ..Jay
>>>
>>>> Date: Wed, 21 Oct 2009 09:21:57 +0200
>>>> From: wagner at elegosoft.com
>>>> To: jay.krell at cornell.edu
>>>> CC: m3devel at elegosoft.com
>>>> Subject: Re: [M3devel] Status of threads for RC4?
>>>>
>>>> Quoting Jay K <jay.krell at cornell.edu>:
>>>>
>>>> > Is it reasonable maybe to rewrite this test in C and see if it  hangs?
>>>> >
>>>> > ie. see if maybe it is an OpenBSD bug?
>>>>
>>>> It doesn't hang with garbage collection turned off, so there must  be
>>>> some unhealthy interaction between that and the thread  implementation.
>>>> I don't think you will be able to narrow it down with a C test.
>>>>
>>>> Olaf
>>>> --
>>>> Olaf Wagner -- elego Software Solutions GmbH
>>>> Gustav-Meyer-Allee 25 / Gebäude 12, 13355 Berlin, Germany
>>>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23
>>> 45 86 95
>>>> http://www.elegosoft.com | Geschäftsführer: Olaf Wagner | Sitz:  Berlin
>>>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr:
>>> DE163214194
>>>>
>>



-- 
Olaf Wagner -- elego Software Solutions GmbH
                Gustav-Meyer-Allee 25 / Gebäude 12, 13355 Berlin, Germany
phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45 86 95
    http://www.elegosoft.com | Geschäftsführer: Olaf Wagner | Sitz: Berlin
Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194