[M3devel] Status of threads for RC4?
Olaf Wagner
wagner at elegosoft.com
Wed Oct 21 16:00:42 CEST 2009
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
More information about the M3devel
mailing list