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

Jay K jay.krell at cornell.edu
Mon Oct 26 10:41:18 CET 2009


 	<F011EB9C-1217-442E-8948-E8B4CF3C3E79 at cs.purdue.edu>
 

 <20091026103508.pzhjoihy8k480oog at mail.elegosoft.com>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0


WIndows threads are ok.
OpenBSD are not currently=2C never have been.
Windows problems are probably in Trestle.
 Have been for many years apparently.
=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
> 		 	   		  =



More information about the M3devel mailing list