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

[Jay K]

Tony,

 I understand "as long as OpenBSD pthreads is userthreads, we might as well use our own" but I don't understand "pthread threading is unlikely to work on OpenBSD". Shouldn't it work pretty ok actually? Except for the suspend/resume stuff?

It should be easy to have OpenBSD custom stuff like Darwin has custom stuff, right?

 

 

I was of the impression that the stack could merely be heap allocated, but perhaps it takes more than that?

get/set/make/swapcontext are not available as far as I know on OpenBSD, but I do have them working on OpenBSD/x86 and OpenBSD/ppc (no OpenBSD/ppc currently to test on, but not a big deal to bring up it and others).

 

 

Regarding Windows I did remove the idle thread cache, which is good and bad.

The removal was mismotivated, and it might be a good thing, might be a bad thing.

 

 - Jay

 


CC: wagner at elegosoft.com; m3devel at elegosoft.com
From: hosking at cs.purdue.edu
To: jay.krell at cornell.edu
Subject: Re: [M3devel] Fwd: Re: Status of threads for RC4?
Date: Mon, 26 Oct 2009 10:07:55 -0400





OpenBSD user-level threading should work one way (using getcontext/setcontext./swapcontext/makecontext if available there) or another (emulating these using setjmp/longjmp and a documented approach to synthesizing thread stacks using sigaltstack).  Pthread threading is unlikely to work on OpenBSD until they fully support rthreads, but since OpenBSD pthreads are user-level we might as well use our own ThreadPosix implementation.  I don't know if the old (current RC branch) ThreadPosix will work on OpenBSD or whether it would be worth moving to the much improved version I implemented this weekend which is now on trunk.


On 26 Oct 2009, at 10:01, Jay K wrote:


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
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20091026/5f4998c0/attachment-0002.html>