[M3devel] User-level threads using makecontext/getcontext/swapcontext

[Jay K]

 - sounds very good

 

 

 - no active target defaults to user threads 

   The "closest" is FreeBSD 4.x. I mean, you know, that is the only one anyone here has expressed a recent desire to use, and used it and it was made to work. He can locally edit m3makefile.

 

 

 - I don't know of any significant platform without pthreads except NT and hypothetical DJGPP (Linux 2.4 mentioned below)

 

 

 - The following I know don't have make/get/set/swapcontext:

   any version of Cygwin, and I suspect not worth worrying about 

   any version of NT, and I suspect not worth worrying about 

     I don't think fibers are viable but maybe.

          Fibers don't interact propertly with any locking construct except Interlocked. e.g. critical sections nor any kernel object "work".

     Win7 has "user mode scheduling" that addresses problems with fibers but I think only on 64bit? 

   any version of OpenBSD 

   Darwin <=10.4; I synthesized them for PowerPC/10.4; you might try that (I found the PowerPC compat on x86 to be not very good though, maybe that was debugging only).

 

 

 - I think HP-UX manpage has strong warnings about these functions, being very version specific/fragile or something. But HP-UX has pthreads.

 

 

 - old Linux 2.4 still seems to be in somewhat active use, in specialized areas -- my router and a networked hard drive I have; pthreads is there I think, but not NPTL.

 

 

I wonder if we should have

  I386_FREEBSD_USERTHREADS

  I386_LINUX_USERTHREADS 

  SPARC_SOLARIS_USERTHREADS?

 

and give them decent test/Hudson/release coverage?

 

Maybe

  I386_FREEBSD4_USERTHREADS 

  I386_LINUX24_USERTHREADS

 

 

To "ghettoize" them via naming only, though they'd actually work and be tested on current systems?

 

That is, you know, make userthreads work a bunch, be more portable, maintainable, great, then what? They still sit unused/unbuilt/untested? How to fix that? At least built/testet?

 

Maybe just with cm3 -D thing, don't release them, just build/test them regularly?

 

 > The advantage of this move will be to eliminate a large swath of "cloned" 

 

Good!

 

Specific questions about specific platforms ask me?

You can see the answer is kind of backwards -- notice how every platform I have introduced I didn't add user threads support for. Question is only then for old/dead/unused/dormant platforms, and most of them DO have pthreads these days. I have a few machines not setup or not powered on -- Irix (32bit and 64bit in one) and AIX (32bit and 64bit in one) and HP-UX/HPPA (32bit and 64bit in one), Linux/IA64 specifically are powered off. VMS/Alpha, VMS/IA64 HP-UX/IA64, Tru64 I haven't gotten up and running yet, but I think they all support pthreads a long time now so no big worry. I also don't have have Linux/PPC64 or Darwin/PPC64 capability yet. (I think after this release Linux/IA64 should be done and will require a small change -- it has "two stacks" to scan.)

 

 > but don't have easy access to existing ABIs for other targets

 

Please try the ssh commands I sent?

That'll give you OpenBSD. FreeBSD maybe but I think it is off. I can provide more but for purposes of this line of questioning doesn't seem criticla.

Birch gives you Linux/AMD64 and, in (slow/VM) a fashion NT and maybe Cygwin.

 

 

 - Jay
 


From: hosking at cs.purdue.edu
To: m3devel at elegosoft.com
Date: Fri, 23 Oct 2009 14:43:59 -0400
Subject: [M3devel] User-level threads using makecontext/getcontext/swapcontext


I have a (slightly rough) derivative version of ThreadPosix working on I386_DARWIN (implemented more along the lines of the current ThreadPThread) which abstracts all the nasty C-isms into ThreadPosixC.c.  I would like to propose that this become our updated user-level threads implementation to complement ThreadPThread and ThreadWin32, but doing so will require reworking the C code for the other targets.  My question is the following: which targets currently default to ThreadPosix (instead of ThreadPThread)?  Do those targets all have makecontext/getcontext/swapcontext (or equivalents that might be simulated with setjmp/longjmp)?  I can make the effort to ensure things work for SOLgnu/SOLsun, *_DARWIN, LINUXLIBC6, but don't have easy access to existing ABIs for other targets.  Can someone else do that?  The advantage of this move will be to eliminate a large swath of "cloned" RTMachine and RTThread implementations and simplify porting.  If we are in agreement on this then I can begin to tidy up and commit my changes.  The advantage of retaining the user-level threads code is its benefit as a live reference implementation of the Modula-3 thread semantics.




Antony Hosking | Associate Professor | Computer Science | Purdue University
305 N. University Street | West Lafayette | IN 47907 | USA
Office +1 765 494 6001 | Mobile +1 765 427 5484

 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20091024/4cd1abfd/attachment-0002.html>