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

Tony Hosking hosking at cs.purdue.edu
Thu Oct 22 03:32:26 CEST 2009 

On 21 Oct 2009, at 20:12, Jay K wrote:

> ps: notice:
>
> >> resumed system calls will return an error value of EINTR

Not a problem.  We already cope with that in ThreadPThread.

>  We probably need to handle that in a bunch of places.
> But some things like read/write will return just having done a  
> partial read/write?

Huh?  Should already be done?

>  Maybe something more cooperative would be easier?
> Or even user threads??
> I do have make/get/set/swapcontext synthesized from setjmp/longjmp  
> on some OpenBSD platforms, like ppc/x86.

These are available for OpenBSD already.  Not sure why you synthesized.

>
>  - Jay
>
> From: jay.krell at cornell.edu
> To: wagner at elegosoft.com
> Date: Wed, 21 Oct 2009 21:07:09 +0000
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] Fwd: Re: Status of threads for RC4?
>
> Not sure how the formatting will come through..but yes.
> Hopefully on all processor architectures.
>
>
> "np" means "not portable", ok
>
>
> http://www.openbsd.org/cgi-bin/man.cgi
>
> appropos suspend
>
> http://www.openbsd.org/cgi-bin/man.cgi?query=pthread_resume_all_np&sektion=3&apropos=0&manpath=OpenBSD+Current&arch=i386
>
> PTHREAD_SUSPEND_NP(3)     OpenBSD Programmer's Manual     
> PTHREAD_SUSPEND_NP(3)
>
> NAME
>      pthread_suspend_np, pthread_suspend_all_np, pthread_resume_np,
>      pthread_resume_all_np - suspend and resume thread(s)
>
> SYNOPSIS
>      #include <pthread.h>
>      #include <pthread_np.h>
>
>      int
>      pthread_suspend_np(pthread_t thread);
>
>      void
>      pthread_suspend_all_np(void);
>
>      int
>      pthread_resume_np(pthread_t thread);
>
>      void
>      pthread_resume_all_np(void);
>
> DESCRIPTION
>      The pthread_suspend_np() function interrupts the given thread  
> and places
>      it in a suspended state.
>
>      The pthread_suspend_all_np() function interrupts all threads  
> except the
>      current thread and places them in a suspended state.
>
>      The pthread_resume_np() function resumes a thread suspended with
>      pthread_suspend_np() or pthread_suspend_all_np().
>
>      The pthread_resume_all_np() function resumes all threads  
> suspended with
>      pthread_suspend_np() or pthread_suspend_all_np().
>
>      The pthread_resume_np() and pthread_resume_all_np() functions  
> have no ef-
>      fect on threads that have not been suspended.
>
>      Suspending and resuming a thread has an effect similar to that  
> of receiv-
>      ing a signal, namely that resumed system calls will return an  
> error value
>      of EINTR.
>
> RETURN VALUES
>      The pthread_suspend_np() and pthread_resume_np() functions fail  
> if:
>
>      [ESRCH]       No thread could be found corresponding to that  
> specified by
>                    the given thread ID.
>
>      The pthread_suspend_np() function fails if:
>
>      [EDEADLK]     Attempt to suspend the current thread.
>
> SEE ALSO
>      pthread_cancel(3), pthreads(3)
>
> STANDARDS
>      The pthread_suspend_np(), pthread_suspend_all_np(),  
> pthread_resume_np()
>      and pthread_resume_all_np() functions are non-portable and may  
> not be
>      supported with the above semantics on other POSIX systems.
>
> OpenBSD 4.5                      May 31,  
> 2007                                1
> NAME | SYNOPSIS | DESCRIPTION | RETURN VALUES | SEE ALSO | STANDARDS
>
>  - Jay
>
>
> From: jay.krell at cornell.edu
> To: wagner at elegosoft.com
> Date: Wed, 21 Oct 2009 13:02:26 -0700
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] Fwd: Re: Status of threads for RC4?
>
> OpenBSD has good documentation.. (man pages)
>
>  - Jay (phone)
>
> On Oct 21, 2009, at 11:05 AM, Olaf Wagner <wagner at elegosoft.com>  
> wrote:
>
> 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
>
> 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/bf0f3ad5/attachment-0002.html>

More information about the M3devel mailing list