[M3devel] User-level threading

[Tony Hosking]

In looking at things again, I am more and more convinced that  
ThreadPosix should be implemented against the standard API for  
makecontext/getcontext/setcontext/swapcontext.  Platforms that do not  
provide these will need to provide an equivalent implementation of  
these routines, similar to what you suggest.  Right now, I know all of
SOLgnu, I386_DARWIN, LINUXLIBC6, FreeBSD should have the necessary  
support.

On Jul 4, 2007, at 2:31 PM, Elmar Stellnberger wrote:

> It seems to be the same message, which I have sent to you.
> Has there been anything new you wanted to tell me?
> Is the setjmp/longjmp replacement of interest?
>
> Elmar Stellnberger wrote:
>> Not long ago I have fixed this problem by replacing setjmp/longjmp  
>> with my own i386 - implementations of these functions for SRC-M3.  
>> The result seems to be stable and correct. However this may be  
>> less favourable than using makecontext since the assembler  
>> routines will only work on i386 hardware. Moreover setjmp/longjmp  
>> are said that they may cause the loss of assignents, because they  
>> do not save certain registers(cx,dx) -> see "Exception semantics"  
>> at http://modula3.elegosoft.com/pm3/pkg/m3compiler/src/ 
>> restrictions.html. Nevertheless possible future changes on make/ 
>> get/setcontext will not be able to affect Modula-3 when extracting  
>> the SP from the context record any more if it does not rely on  
>> glibc functions. Another solution is to link against the old glibc  
>> files (unpacked into /lib/anc):
>>> ldd $(which m3build)
>> linux-gate.so.1 => (0xffffe000) libm3front.so.1 => /usr/local/m3/ 
>> lib/m3/pkg/m3front/LINUXLIBC6/libm3front.so.1 (0xb7dd2000) libm.so. 
>> 6 => /lib/anc/9.3/libm.so.6 (0xb7daf000) libc.so.6 => /lib/anc/9.3/ 
>> libc.so.6 (0xb7c95000) /lib/anc/9.3/ld-linux.so.2 (0xb7ef8000)  
>> Please tell me if you are intereseted in any of both solutions. I  
>> would suppose a solution for CM3 not to differ that much. Yours,  
>> Elmar Stellnberger Tony Hosking wrote:
>>> I have a question that may influence the direction we take with  
>>> user-level threading support. Currently, user-level threading is  
>>> broken on platforms that implement secure setjmp/longjmp via  
>>> encryption since hacking the jump buffers the way we currently do  
>>> for user-level threading triggers longjmp errors. A better  
>>> alternative is to use makecontext/getcontext/setcontext on  
>>> platforms that support it. For example, I know of the following  
>>> situation for the targets I track: Target System (pthreads)  
>>> threads User (setjmp/longjmp) threads User (getcontext/ 
>>> setcontext) threads LINUXLIBC6 YES NO unimplemented SOLgnu YES  
>>> unimplemented YES (but not using makecontext) PPC_DARWIN YES NO  
>>> no getcontext/setcontext I386_DARWIN YES NO no getcontext/ 
>>> setcontext FreeBSD NO YES unimplemented Ideally, we would  
>>> implement all user-level threading using makecontext and friends,  
>>> but my question is how many of our user-level threading targets  
>>> actually support that API? One strategy would be to re-implement  
>>> user-level threading using makecontext, etc., but fake up  
>>> makecontext support, etc., on those targets that don't have it. I  
>>> would hate to lose the user-level thread support just because it  
>>> makes sense in some situations (e.g., embedded, uni-processor).
>