
<html>

<head>

<style><!--

.hmmessage P

{

margin:0px;

padding:0px

}

body.hmmessage

{

font-size: 10pt;

font-family:Verdana

}

--></style>

</head>

<body class='hmmessage'>

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

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

It is fixed in release.<BR>

 <BR>

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

 <BR>

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

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

I'm still investigating.<BR>

 <BR>

 - Jay<BR><BR> <BR>> Date: Mon, 26 Oct 2009 13:49:24 +0100<BR>> From: wagner@elegosoft.com<BR>> To: jay.krell@cornell.edu<BR>> CC: m3devel@elegosoft.com<BR>> Subject: Re: [M3devel] Fwd: Re: Status of threads for RC4?<BR>> <BR>> Quoting Jay K <jay.krell@cornell.edu>:<BR>> <BR>> > WIndows threads are ok.<BR>> In the release branch, too?<BR>> <BR>> > OpenBSD are not currently=2C never have been.<BR>> Do we have a work-around or are we going to ignore this for the release?<BR>> <BR>> > Windows problems are probably in Trestle.<BR>> > Have been for many years apparently.<BR>> Do we wait for a fix here for RC4?<BR>> <BR>> I can see that you and Tony are quite busy, but there are no visible<BR>> changes for the release status.<BR>> <BR>> Olaf<BR>> <BR>> > =20<BR>> > - Jay<BR>> ><BR>> > ----------------------------------------<BR>> >> Date: Mon=2C 26 Oct 2009 10:35:08 +0100<BR>> >> From: wagner@elegosoft.com<BR>> >> To: hosking@cs.purdue.edu<BR>> >> CC: jay.krell@cornell.edu=3B m3devel@elegosoft.com<BR>> >> Subject: Re: [M3devel] Fwd: Re: Status of threads for RC4?<BR>> >><BR>> >> Hi again=2C<BR>> >><BR>> >> I'm still uncertain regarding the thread status. Hudson hasn't built<BR>> >> anything for about a month=2C so there have been no check-ins to the<BR>> >> release branch.<BR>> >><BR>> >> (1) Has the OpenBSD problem been fixed or worked around?<BR>> >> If so=2C what are the relevant changes that should me merged from<BR>> >> trunk?<BR>> >><BR>> >> The ChangeLog shows a lot of commits on head...<BR>> >><BR>> >> (2) Is there still a problem in Windows threads?<BR>> >> Or are we just chasing a general access violation due to an<BR>> >> unknown reason?<BR>> >><BR>> >> Again=2C is this ongoing or should some changes be merged for<BR>> >> the release?<BR>> >><BR>> >> Olaf<BR>> >><BR>> >> Quoting Tony Hosking :<BR>> >><BR>> >>> On 21 Oct 2009=2C at 20:12=2C Jay K wrote:<BR>> >>><BR>> >>>> ps: notice:<BR>> >>>><BR>> >>>>>> resumed system calls will return an error value of EINTR<BR>> >>><BR>> >>> Not a problem. We already cope with that in ThreadPThread.<BR>> >>><BR>> >>>> We probably need to handle that in a bunch of places.<BR>> >>>> But some things like read/write will return just having done a<BR>> >>>> partial read/write?<BR>> >>><BR>> >>> Huh? Should already be done?<BR>> >>><BR>> >>>> Maybe something more cooperative would be easier?<BR>> >>>> Or even user threads??<BR>> >>>> I do have make/get/set/swapcontext synthesized from setjmp/longjmp<BR>> >>>> on some OpenBSD platforms=2C like ppc/x86.<BR>> >>><BR>> >>> These are available for OpenBSD already. Not sure why you synthesized.<BR>> >>><BR>> >>>><BR>> >>>> - Jay<BR>> >>>><BR>> >>>> From: jay.krell@cornell.edu<BR>> >>>> To: wagner@elegosoft.com<BR>> >>>> Date: Wed=2C 21 Oct 2009 21:07:09 +0000<BR>> >>>> CC: m3devel@elegosoft.com<BR>> >>>> Subject: Re: [M3devel] Fwd: Re: Status of threads for RC4?<BR>> >>>><BR>> >>>> Not sure how the formatting will come through..but yes.<BR>> >>>> Hopefully on all processor architectures.<BR>> >>>><BR>> >>>><BR>> >>>> "np" means "not portable"=2C ok<BR>> >>>><BR>> >>>><BR>> >>>> http://www.openbsd.org/cgi-bin/man.cgi<BR>> >>>><BR>> >>>> appropos suspend<BR>> >>>><BR>> >>>> http://www.openbsd.org/cgi-bin/man.cgi?query=3Dpthread_resume_all_np&se=<BR>> > ktion=3D3&apropos=3D0&manpath=3DOpenBSD+Current&arch=3Di386<BR>> >>>><BR>> >>>> PTHREAD_SUSPEND_NP(3) OpenBSD Programmer's Manual<BR>> >>>> PTHREAD_SUSPEND_NP(3)<BR>> >>>><BR>> >>>> NAME<BR>> >>>> pthread_suspend_np=2C pthread_suspend_all_np=2C pthread_resume_np=2C<BR>> >>>> pthread_resume_all_np - suspend and resume thread(s)<BR>> >>>><BR>> >>>> SYNOPSIS<BR>> >>>> #include=20<BR>> >>>> #include=20<BR>> >>>><BR>> >>>> int<BR>> >>>> pthread_suspend_np(pthread_t thread)=3B<BR>> >>>><BR>> >>>> void<BR>> >>>> pthread_suspend_all_np(void)=3B<BR>> >>>><BR>> >>>> int<BR>> >>>> pthread_resume_np(pthread_t thread)=3B<BR>> >>>><BR>> >>>> void<BR>> >>>> pthread_resume_all_np(void)=3B<BR>> >>>><BR>> >>>> DESCRIPTION<BR>> >>>> The pthread_suspend_np() function interrupts the given thread<BR>> >>>> and places<BR>> >>>> it in a suspended state.<BR>> >>>><BR>> >>>> The pthread_suspend_all_np() function interrupts all threads except the<BR>> >>>> current thread and places them in a suspended state.<BR>> >>>><BR>> >>>> The pthread_resume_np() function resumes a thread suspended with<BR>> >>>> pthread_suspend_np() or pthread_suspend_all_np().<BR>> >>>><BR>> >>>> The pthread_resume_all_np() function resumes all threads suspended with<BR>> >>>> pthread_suspend_np() or pthread_suspend_all_np().<BR>> >>>><BR>> >>>> The pthread_resume_np() and pthread_resume_all_np() functions<BR>> >>>> have no ef-<BR>> >>>> fect on threads that have not been suspended.<BR>> >>>><BR>> >>>> Suspending and resuming a thread has an effect similar to that<BR>> >>>> of receiv-<BR>> >>>> ing a signal=2C namely that resumed system calls will return an<BR>> >>>> error value<BR>> >>>> of EINTR.<BR>> >>>><BR>> >>>> RETURN VALUES<BR>> >>>> The pthread_suspend_np() and pthread_resume_np() functions fail if:<BR>> >>>><BR>> >>>> [ESRCH] No thread could be found corresponding to that<BR>> >>>> specified by<BR>> >>>> the given thread ID.<BR>> >>>><BR>> >>>> The pthread_suspend_np() function fails if:<BR>> >>>><BR>> >>>> [EDEADLK] Attempt to suspend the current thread.<BR>> >>>><BR>> >>>> SEE ALSO<BR>> >>>> pthread_cancel(3)=2C pthreads(3)<BR>> >>>><BR>> >>>> STANDARDS<BR>> >>>> The pthread_suspend_np()=2C pthread_suspend_all_np()=2C pthread_resume_=<BR>> > np()<BR>> >>>> and pthread_resume_all_np() functions are non-portable and may not be<BR>> >>>> supported with the above semantics on other POSIX systems.<BR>> >>>><BR>> >>>> OpenBSD 4.5 May 31=2C 2007<BR>> >>>> 1<BR>> >>>> NAME | SYNOPSIS | DESCRIPTION | RETURN VALUES | SEE ALSO | STANDARDS<BR>> >>>><BR>> >>>> - Jay<BR>> >>>><BR>> >>>><BR>> >>>> From: jay.krell@cornell.edu<BR>> >>>> To: wagner@elegosoft.com<BR>> >>>> Date: Wed=2C 21 Oct 2009 13:02:26 -0700<BR>> >>>> CC: m3devel@elegosoft.com<BR>> >>>> Subject: Re: [M3devel] Fwd: Re: Status of threads for RC4?<BR>> >>>><BR>> >>>> OpenBSD has good documentation.. (man pages)<BR>> >>>><BR>> >>>> - Jay (phone)<BR>> >>>><BR>> >>>> On Oct 21=2C 2009=2C at 11:05 AM=2C Olaf Wagner wrote:<BR>> >>>><BR>> >>>> Stefan=2C<BR>> >>>><BR>> >>>> you are our OpenBSD fan=2C aren't you? Can you answer this?<BR>> >>>><BR>> >>>> Olaf<BR>> >>>><BR>> >>>> ----- Forwarded message from hosking@cs.purdue.edu -----<BR>> >>>> Date: Wed=2C 21 Oct 2009 12:06:12 -0400<BR>> >>>> From: Tony Hosking=20<BR>> >>>> Reply-To: Tony Hosking=20<BR>> >>>> Subject: Re: [M3devel] Status of threads for RC4?<BR>> >>>> To: Olaf Wagner=20<BR>> >>>> Cc: Jay K =2C m3devel=20<BR>> >>>><BR>> >>>> This is a known problem for the user-level pthreads on OpenBSD.<BR>> >>>><BR>> >>>> Quick question: does OpenBSD support pthread_suspend=2C pthread_resume?<BR>> >>>> If so then we could work avoid the signals entirely (as we do on OS<BR>> >>>> X). All that is needed is implementation of RTMachine.SuspendThread=2C<BR>> >>>> RTMachine.ResumeThread and RTMachine.GetState for OpenBSD targets.<BR>> >>>><BR>> >>>> On 21 Oct 2009=2C at 10:04=2C Olaf Wagner wrote:<BR>> >>>><BR>> >>>> Quoting Tony Hosking :<BR>> >>>><BR>> >>>> Yes=2C a C test can tell us if threads waiting on mutexes are able to<BR>> >>>> receive pthread_kill signals.<BR>> >>>><BR>> >>>> Could you add such a simple test program somewhere in m3tests or<BR>> >>>> m3core/tests? We could also use that for a bug report to the<BR>> >>>> OpenBSD developers (they won't like to install m3 to reproduce<BR>> >>>> the error).<BR>> >>>><BR>> >>>> Olaf<BR>> >>>><BR>> >>>> On 21 Oct 2009=2C at 03:21=2C Olaf Wagner wrote:<BR>> >>>><BR>> >>>> Quoting Jay K :<BR>> >>>><BR>> >>>> Is it reasonable maybe to rewrite this test in C and see if it hangs?<BR>> >>>><BR>> >>>> ie. see if maybe it is an OpenBSD bug?<BR>> >>>><BR>> >>>> It doesn't hang with garbage collection turned off=2C so there must be<BR>> >>>> some unhealthy interaction between that and the thread implementation.<BR>> >>>> I don't think you will be able to narrow it down with a C test.<BR>> >>>><BR>> >>>> Olaf<BR>> >>>> --<BR>> >>>> Olaf Wagner -- elego Software Solutions GmbH<BR>> >>>> Gustav-Meyer-Allee 25 / Geb=E4ude 12=2C 13355 Berlin=2C Germany<BR>> >>>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30<BR>> >>>> 23 45 86 95<BR>> >>>> http://www.elegosoft.com | Gesch=E4ftsf=FChrer: Olaf Wagner | Sitz: Ber=<BR>> > lin<BR>> >>>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr:<BR>> >>>> DE163214194<BR>> >>>><BR>> >>>><BR>> >>>><BR>> >>>><BR>> >>>> --<BR>> >>>> Olaf Wagner -- elego Software Solutions GmbH<BR>> >>>> Gustav-Meyer-Allee 25 / Geb=E4ude 12=2C 13355 Berlin=2C Germany<BR>> >>>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23<BR>> >>>> 45 86 95<BR>> >>>> http://www.elegosoft.com | Gesch=E4ftsf=FChrer: Olaf Wagner | Sitz: Ber=<BR>> > lin<BR>> >>>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr:<BR>> >>>> DE163214194<BR>> >>>><BR>> >>>><BR>> >>>><BR>> >>>><BR>> >>>> ----- End forwarded message -----<BR>> >>>><BR>> >>>><BR>> >>>> --<BR>> >>>> Olaf Wagner -- elego Software Solutions GmbH<BR>> >>>> Gustav-Meyer-Allee 25 / Geb=E4ude 12=2C 13355 Berlin=2C Germany<BR>> >>>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23<BR>> >>>> 45 86 95<BR>> >>>> http://www.elegosoft.com | Gesch=E4ftsf=FChrer: Olaf Wagner | Sitz: Ber=<BR>> > lin<BR>> >>>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr:<BR>> >>>> DE163214194<BR>> >>>><BR>> >>>> This is a known problem for the user-level pthreads on OpenBSD.<BR>> >>>><BR>> >>>> Quick question: does OpenBSD support pthread_suspend=2C<BR>> >>>> pthread_resume? If so then we could work avoid the signals entirely<BR>> >>>> (as we do on OS X). All that is needed is implementation of<BR>> >>>> RTMachine.SuspendThread=2C RTMachine.ResumeThread and<BR>> >>>> RTMachine.GetState for OpenBSD targets.<BR>> >>>><BR>> >>>> On 21 Oct 2009=2C at 10:04=2C Olaf Wagner wrote:<BR>> >>>><BR>> >>>> Quoting Tony Hosking :<BR>> >>>><BR>> >>>> Yes=2C a C test can tell us if threads waiting on mutexes are able to<BR>> >>>> receive pthread_kill signals.<BR>> >>>><BR>> >>>> Could you add such a simple test program somewhere in m3tests or<BR>> >>>> m3core/tests? We could also use that for a bug report to the<BR>> >>>> OpenBSD developers (they won't like to install m3 to reproduce<BR>> >>>> the error).<BR>> >>>><BR>> >>>> Olaf<BR>> >>>><BR>> >>>> On 21 Oct 2009=2C at 03:21=2C Olaf Wagner wrote:<BR>> >>>><BR>> >>>> Quoting Jay K :<BR>> >>>><BR>> >>>> Is it reasonable maybe to rewrite this test in C and see if it hangs?<BR>> >>>><BR>> >>>> ie. see if maybe it is an OpenBSD bug?<BR>> >>>><BR>> >>>> It doesn't hang with garbage collection turned off=2C so there must be<BR>> >>>> some unhealthy interaction between that and the thread implementation.<BR>> >>>> I don't think you will be able to narrow it down with a C test.<BR>> >>>><BR>> >>>> Olaf<BR>> >>>> --<BR>> >>>> Olaf Wagner -- elego Software Solutions GmbH<BR>> >>>> Gustav-Meyer-Allee 25 / Geb=E4ude 12=2C 13355 Berlin=2C Germany<BR>> >>>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30<BR>> >>>> 23 45 86 95<BR>> >>>> http://www.elegosoft.com | Gesch=E4ftsf=FChrer: Olaf Wagner | Sitz: Ber=<BR>> > lin<BR>> >>>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr:<BR>> >>>> DE163214194<BR>> >>>><BR>> >>>><BR>> >>>><BR>> >>>><BR>> >>>> --<BR>> >>>> Olaf Wagner -- elego Software Solutions GmbH<BR>> >>>> Gustav-Meyer-Allee 25 / Geb=E4ude 12=2C 13355 Berlin=2C Germany<BR>> >>>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23<BR>> >>>> 45 86 95<BR>> >>>> http://www.elegosoft.com | Gesch=E4ftsf=FChrer: Olaf Wagner | Sitz: Ber=<BR>> > lin<BR>> >>>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr:<BR>> >>>> DE163214194<BR>> >>>><BR>> >>>><BR>> >>>><BR>> >><BR>> >><BR>> >><BR>> >> --<BR>> >> Olaf Wagner -- elego Software Solutions GmbH<BR>> >> Gustav-Meyer-Allee 25 / Geb=E4ude 12=2C 13355 Berlin=2C Germany<BR>> >> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 9=<BR>> > 5<BR>> >> http://www.elegosoft.com | Gesch=E4ftsf=FChrer: Olaf Wagner | Sitz: Berli=<BR>> > n<BR>> >> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214=<BR>> > 194<BR>> >> =<BR>> ><BR>> <BR>> <BR>> <BR>> -- <BR>> Olaf Wagner -- elego Software Solutions GmbH<BR>> Gustav-Meyer-Allee 25 / Geb�ude 12, 13355 Berlin, Germany<BR>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95<BR>> http://www.elegosoft.com | Gesch�ftsf�hrer: Olaf Wagner | Sitz: Berlin<BR>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194<BR>> <BR>                                       </body>

</html>