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

Thu Oct 22 07:24:10 CEST 2009

> Huh?  Should already be done?

Could be.

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

Not that I see.
They probably don't scramble in setjmp/longjmp though? (else mine wouldn't work) but making setjmp work is almost the same work as building get/set/make/swapcontext on top of it, gotta poke around in the jmpbuf either way.

 - Jay

From: hosking at cs.purdue.edu
To: jay.krell at cornell.edu
Date: Wed, 21 Oct 2009 21:32:26 -0400
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] Fwd: Re: Status of threads for RC4?

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/20091022/8a48c927/attachment-0002.html>