Thread support in 0.10 on OpenBSD

[Daniel Veillard]

[Had to repost this message which bounced due to too strict checking
 for mails loops on the mailing list, Daniel ]

Robert S. Thau Wrote:

...in cross-platform development, the simpler you can keep your build
environments, and the less you constrain them, the better.

Having done extensive cross-platform development myself over the years,
I have found that dependence on undocumented internal compiler features
(such as the register assignment layout in the jmp_buf) lead to more
problems than they are ever worth. These things tend to be unstable from
compiler release to release and between the compilers of different
vendors.

Although the inline assembler directive may be different between
compilers of different vendors, the feature is stable from release to
release. The stack pointer register name used in the directive is also
stable. Once a port is completed using these well documented directives,
it need not be looked at again.

It can be made simpler by #including a file from the platform specific
directory which includes a #define'd single assembler directive. The
included file would be used directly at the point in the code where the
instruction is needed. This isolates and carefully contains the
platform-specific code without disrupting the sensitve scheduler code
which remains platform-neutral.

Sorry for the long response, but I fear your previous reply may have
misrepresented the issues. This is all probably a moot point though
since Tim has decided to stay with the current implementation and deal
with any problems if they occur.

-- Miller
> ----------
> From: 	Robert S. Thau
> Reply To: 	kaffe at rufus.w3.org
> Sent: 	Tuesday, March 31, 1998 6:28 PM
> To: 	kaffe at rufus.w3.org
> Subject: 	RE: Thread support in 0.10 on OpenBSD
> 
> Miller Abel writes:
>  > If assembler is permitted, a simpler and more maintainable solution
> is
>  > to use a single line of assembler to load the initial stack pointer
>  > value when a thread is created. Then all that is required is
>  > setjmp/longjmp. The jmp_buf structures are simply saved with the
> thread
>  > data (and one for the scheduler context) and are neither inspected
> nor
>  > modified.
> 
> The downside is that this drags you into either mixed-language
> development, compiler-dependant assembler escapes, or both.  Forcing
> people to use one compiler on platforms where other decent compilers
> are available doesn't always work out well.  (Among other things,
> there are Unix platforms where there's an extra-cost vendor compiler
> which isn't necessarily as widely deployed as gcc, but generates
> noticably better code).   Of course, these considerations don't
> necessarily apply to the embedded code for a PBX, but in
> cross-platform development, the simpler you can keep your build
> environments, and the less you constrain them, the better.
> 
> (I only resorted to assembler on one platform --- AIX --- and then
> only for something (longjmp error trapping) which I couldn't figure
> out how to accomplish in anything resembling C). 
> 
> Hopefully, this isn't too far off topic; I'm posting mainly because
> this may be of interest to people who are considering new kaffe ports.
> 
> rst
> 

-- 
Daniel.Veillard at w3.org | W3C  MIT/LCS  NE43-344  | Today's Bookmarks :
Tel : +1 617 253 5884  | 545 Technology Square   | Linux, WWW, rpm2html,
Fax : +1 617 258 5999  | Cambridge, MA 02139 USA | badminton, Kaffe,
http://www.w3.org/People/W3Cpeople.html#Veillard | HTTP-NG and Amaya.