[M3devel] Fwd: Re: Status of threads for RC4?
Olaf Wagner
wagner at elegosoft.com
Mon Oct 26 13:49:24 CET 2009
Quoting Jay K <jay.krell at cornell.edu>:
> WIndows threads are ok.
In the release branch, too?
> OpenBSD are not currently=2C never have been.
Do we have a work-around or are we going to ignore this for the release?
> Windows problems are probably in Trestle.
> Have been for many years apparently.
Do we wait for a fix here for RC4?
I can see that you and Tony are quite busy, but there are no visible
changes for the release status.
Olaf
> =20
> - Jay
>
> ----------------------------------------
>> Date: Mon=2C 26 Oct 2009 10:35:08 +0100
>> From: wagner at elegosoft.com
>> To: hosking at cs.purdue.edu
>> CC: jay.krell at cornell.edu=3B m3devel at elegosoft.com
>> Subject: Re: [M3devel] Fwd: Re: Status of threads for RC4?
>>
>> Hi again=2C
>>
>> I'm still uncertain regarding the thread status. Hudson hasn't built
>> anything for about a month=2C so there have been no check-ins to the
>> release branch.
>>
>> (1) Has the OpenBSD problem been fixed or worked around?
>> If so=2C 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=2C is this ongoing or should some changes be merged for
>> the release?
>>
>> Olaf
>>
>> Quoting Tony Hosking :
>>
>>> On 21 Oct 2009=2C at 20:12=2C 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=2C 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=2C 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"=2C ok
>>>>
>>>>
>>>> http://www.openbsd.org/cgi-bin/man.cgi
>>>>
>>>> appropos suspend
>>>>
>>>> http://www.openbsd.org/cgi-bin/man.cgi?query=3Dpthread_resume_all_np&se=
> ktion=3D3&apropos=3D0&manpath=3DOpenBSD+Current&arch=3Di386
>>>>
>>>> PTHREAD_SUSPEND_NP(3) OpenBSD Programmer's Manual
>>>> PTHREAD_SUSPEND_NP(3)
>>>>
>>>> NAME
>>>> pthread_suspend_np=2C pthread_suspend_all_np=2C pthread_resume_np=2C
>>>> pthread_resume_all_np - suspend and resume thread(s)
>>>>
>>>> SYNOPSIS
>>>> #include=20
>>>> #include=20
>>>>
>>>> int
>>>> pthread_suspend_np(pthread_t thread)=3B
>>>>
>>>> void
>>>> pthread_suspend_all_np(void)=3B
>>>>
>>>> int
>>>> pthread_resume_np(pthread_t thread)=3B
>>>>
>>>> void
>>>> pthread_resume_all_np(void)=3B
>>>>
>>>> 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=2C 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)=2C pthreads(3)
>>>>
>>>> STANDARDS
>>>> The pthread_suspend_np()=2C pthread_suspend_all_np()=2C 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=2C 2007
>>>> 1
>>>> NAME | SYNOPSIS | DESCRIPTION | RETURN VALUES | SEE ALSO | STANDARDS
>>>>
>>>> - Jay
>>>>
>>>>
>>>> From: jay.krell at cornell.edu
>>>> To: wagner at elegosoft.com
>>>> Date: Wed=2C 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=2C 2009=2C at 11:05 AM=2C Olaf Wagner wrote:
>>>>
>>>> Stefan=2C
>>>>
>>>> you are our OpenBSD fan=2C aren't you? Can you answer this?
>>>>
>>>> Olaf
>>>>
>>>> ----- Forwarded message from hosking at cs.purdue.edu -----
>>>> Date: Wed=2C 21 Oct 2009 12:06:12 -0400
>>>> From: Tony Hosking=20
>>>> Reply-To: Tony Hosking=20
>>>> Subject: Re: [M3devel] Status of threads for RC4?
>>>> To: Olaf Wagner=20
>>>> Cc: Jay K =2C m3devel=20
>>>>
>>>> This is a known problem for the user-level pthreads on OpenBSD.
>>>>
>>>> Quick question: does OpenBSD support pthread_suspend=2C 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=2C
>>>> RTMachine.ResumeThread and RTMachine.GetState for OpenBSD targets.
>>>>
>>>> On 21 Oct 2009=2C at 10:04=2C Olaf Wagner wrote:
>>>>
>>>> Quoting Tony Hosking :
>>>>
>>>> Yes=2C 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=2C at 03:21=2C Olaf Wagner wrote:
>>>>
>>>> Quoting Jay K :
>>>>
>>>> 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=2C 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=E4ude 12=2C 13355 Berlin=2C 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=E4ftsf=FChrer: Olaf Wagner | Sitz: Ber=
> lin
>>>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr:
>>>> DE163214194
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Olaf Wagner -- elego Software Solutions GmbH
>>>> Gustav-Meyer-Allee 25 / Geb=E4ude 12=2C 13355 Berlin=2C 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=E4ftsf=FChrer: Olaf Wagner | Sitz: Ber=
> lin
>>>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr:
>>>> DE163214194
>>>>
>>>>
>>>>
>>>>
>>>> ----- End forwarded message -----
>>>>
>>>>
>>>> --
>>>> Olaf Wagner -- elego Software Solutions GmbH
>>>> Gustav-Meyer-Allee 25 / Geb=E4ude 12=2C 13355 Berlin=2C 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=E4ftsf=FChrer: Olaf Wagner | Sitz: Ber=
> lin
>>>> 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=2C
>>>> 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=2C RTMachine.ResumeThread and
>>>> RTMachine.GetState for OpenBSD targets.
>>>>
>>>> On 21 Oct 2009=2C at 10:04=2C Olaf Wagner wrote:
>>>>
>>>> Quoting Tony Hosking :
>>>>
>>>> Yes=2C 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=2C at 03:21=2C Olaf Wagner wrote:
>>>>
>>>> Quoting Jay K :
>>>>
>>>> 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=2C 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=E4ude 12=2C 13355 Berlin=2C 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=E4ftsf=FChrer: Olaf Wagner | Sitz: Ber=
> lin
>>>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr:
>>>> DE163214194
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Olaf Wagner -- elego Software Solutions GmbH
>>>> Gustav-Meyer-Allee 25 / Geb=E4ude 12=2C 13355 Berlin=2C 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=E4ftsf=FChrer: Olaf Wagner | Sitz: Ber=
> lin
>>>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr:
>>>> DE163214194
>>>>
>>>>
>>>>
>>
>>
>>
>> --
>> Olaf Wagner -- elego Software Solutions GmbH
>> Gustav-Meyer-Allee 25 / Geb=E4ude 12=2C 13355 Berlin=2C Germany
>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 9=
> 5
>> http://www.elegosoft.com | Gesch=E4ftsf=FChrer: Olaf Wagner | Sitz: Berli=
> n
>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214=
> 194
>> =
>
--
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