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

Jay K jay.krell at cornell.edu
Mon Oct 26 15:01:10 CET 2009 

Windows threads should be ok for release..though..there is definitely divergence in head.

There was really just one main problem in Win32 threads, a copy/paste error I made a few months ago.

It is fixed in release.

 

OpenBSD we know the fix but not sure we'll get to it.

 

There are still problems with mentor and/or Juno and/or Trestle, all Windows specific.

To some extent there are problems going back years, but things seem to be much worse lately.

I'm still investigating.

 

 - Jay

 
> Date: Mon, 26 Oct 2009 13:49:24 +0100
> From: wagner at elegosoft.com
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] Fwd: Re: Status of threads for RC4?
> 
> 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
> 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20091026/d298124d/attachment-0002.html>

More information about the M3devel mailing list