[M3devel] Fwd: Re: Status of threads for RC4?

[Olaf Wagner]

Stefan,

you are our OpenBSD fan, aren't you? Can you answer this?

Olaf

----- Forwarded message from hosking at cs.purdue.edu -----
     Date: Wed, 21 Oct 2009 12:06:12 -0400
     From: Tony Hosking <hosking at cs.purdue.edu>
Reply-To: Tony Hosking <hosking at cs.purdue.edu>
  Subject: Re: [M3devel] Status of threads for RC4?
       To: Olaf Wagner <wagner at elegosoft.com>
       Cc: Jay K <jay.krell at cornell.edu>, m3devel <m3devel at elegosoft.com>

This is a known problem for the user-level pthreads on OpenBSD.

Quick question: does OpenBSD support pthread_suspend, pthread_resume?
If so then we could work avoid the signals entirely (as we do on OS
X).  All that is needed is implementation of RTMachine.SuspendThread,
RTMachine.ResumeThread and RTMachine.GetState for OpenBSD targets.

On 21 Oct 2009, at 10:04, Olaf Wagner wrote:

> Quoting Tony Hosking <hosking at cs.purdue.edu>:
>
>> Yes, a C test can tell us if threads waiting on mutexes are able to
>> receive pthread_kill signals.
>
> Could you add such a simple test program somewhere in m3tests or
> m3core/tests? We could also use that for a bug report to the
> OpenBSD developers (they won't like to install m3 to reproduce
> the error).
>
> Olaf
>
>> On 21 Oct 2009, at 03:21, Olaf Wagner wrote:
>>
>>> 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
>



----- End forwarded message -----


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

-------------- next part --------------
This is a known problem for the user-level pthreads on OpenBSD.

Quick question: does OpenBSD support pthread_suspend, pthread_resume?   
If so then we could work avoid the signals entirely (as we do on OS  
X).  All that is needed is implementation of RTMachine.SuspendThread,  
RTMachine.ResumeThread and RTMachine.GetState for OpenBSD targets.

On 21 Oct 2009, at 10:04, Olaf Wagner wrote:

> Quoting Tony Hosking <hosking at cs.purdue.edu>:
>
>> Yes, a C test can tell us if threads waiting on mutexes are able to
>> receive pthread_kill signals.
>
> Could you add such a simple test program somewhere in m3tests or
> m3core/tests? We could also use that for a bug report to the
> OpenBSD developers (they won't like to install m3 to reproduce
> the error).
>
> Olaf
>
>> On 21 Oct 2009, at 03:21, Olaf Wagner wrote:
>>
>>> 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
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20091021/bc0de985/attachment-0001.html>