[M3devel] User-level threading

[Elmar Stellnberger]

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).
>>
>>
>>
>>     
>
>
>
>   

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20070704/ebc5836b/attachment-0004.html>