[M3devel] Fwd: Re: Status of threads for RC4?
Olaf Wagner
wagner at elegosoft.com
Mon Oct 26 10:35:08 CET 2009
Hi again,
I'm still uncertain regarding the thread status. Hudson hasn't built
anything for about a month, so there have been no check-ins to the
release branch.
(1) Has the OpenBSD problem been fixed or worked around?
If so, what are the relevant changes that should me merged from
trunk?
The ChangeLog shows a lot of commits on head...
(2) Is there still a problem in Windows threads?
Or are we just chasing a general access violation due to an
unknown reason?
Again, is this ongoing or should some changes be merged for
the release?
Olaf
Quoting Tony Hosking <hosking at cs.purdue.edu>:
> 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
>>
>>
>>
--
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