
<html>

<head>

<style>

.hmmessage P

{

margin:0px;

padding:0px

}

body.hmmessage

{

font-size: 10pt;

font-family:Verdana

}

</style>

</head>

<body class='hmmessage'>

I think you didn't realize some of what I was lumping into "link time".<BR>

 <BR>

It could mean "constructing main to pass a parameter to RTLinker".<BR>

Or setting a flag in the Main module (like how gengc/incgc flags are set<BR>

in all modules, but this is a more difficult and likely wasteful change,<BR>

no need to burn a bit in all modules, just the main module).<BR>

 <BR>

 <BR>

I still think function pointers would suffice, costing zero or one instruction per function call..<BR>

But I haven't tried it yet.<BR>

 <BR>

 <BR>

Systems with "build variants" tend to get "explosive" -- combinatorial explosions of "configurations".<BR>

Boost is good (bad) example of this.<BR>

 <BR>

 - Jay<BR><BR><BR>> Date: Thu, 8 Jan 2009 14:38:25 +0100<BR>> From: wagner@elegosoft.com<BR>> To: m3devel@elegosoft.com<BR>> Subject: Re: [M3devel] dynamic chose between user/kernel threads?<BR>> <BR>> As I noted earlier, I think that a link-time choice between<BR>> (M3) user and system (kernel/p) threads would be completely<BR>> satisfactory. Default could be pthreads/system threads, and<BR>> cm3 -uthreads or cm3 -m3threads could substitute the old but<BR>> efficient M3 implementation (with proper getcontext/makecontext<BR>> for all target platforms ;-).<BR>> <BR>> Olaf<BR>> <BR>> Quoting Tony Hosking <hosking@cs.purdue.edu>:<BR>> <BR>> > On 8 Jan 2009, at 14:10, Jay wrote:<BR>> ><BR>> >> Olaf understood the point (I think). :)<BR>> >><BR>> >> Some programs, people say, and I believe, run "better" (faster, <BR>> >> without running out of address space) with user threads instead of <BR>> >> kernel threads.<BR>> ><BR>> > Is this still true for modern kernel thread systems?<BR>> ><BR>> >> On systems that have both.<BR>> >> A good example might be a program that needs lots of threads and <BR>> >> therefore small stacks, and the kernel threads, due to code below <BR>> >> the Modula-3 runtime, might force fairly large stacks. (Such a <BR>> >> program might have to adjust thread size differently for different <BR>> >> threads, and only call into the underlying system on threads with <BR>> >> larger stacks.)<BR>> ><BR>> > In a systems programming language like Modula-3 shouldn't threads have<BR>> > a relationship to the system?<BR>> ><BR>> >> It might be nice for such programs to be able to mandate or request <BR>> >> (two slightly different things) that the user thread library be <BR>> >> used by them, even if the platform's default is to use kernel <BR>> >> threads.<BR>> ><BR>> > This will need to be a link-time distinction. I would hate to have<BR>> > both kernel and user thread code live in the same compiled run-time<BR>> > system.<BR>> ><BR>> >> The only minor detail then is, how to express the request, and the <BR>> >> precise meaning.<BR>> >> It is a request or a mandate?<BR>> ><BR>> > I see no problem with factoring out the threads subsystem as a<BR>> > separate library and linking accordingly.<BR>> ><BR>> >> As well, if the issue is address space, sholud there a "built in" <BR>> >> way to only make the request on 32bit platforms, or should uses <BR>> >> manually say if equal (WORD_SIZE, "32BITS")?<BR>> >><BR>> >> Is it a boolean or an enum?<BR>> >> Cygwin might conceivably get pthreads support (Cygwin has it, but <BR>> >> Modula-3/Cygwin does not).<BR>> >> Therefore, is the choice among "posix" threads, "pthreads" and "NT" <BR>> >> threads?<BR>> >> Or just user vs. kernel?<BR>> ><BR>> > I would argue for user vs. kernel.<BR>> ><BR>> >> I think the "important" part here is easy to implement.<BR>> >> But again..<BR>> ><BR>> > And managing the state-space explosion that multiple choices might<BR>> > entail. I would like to avoid that.<BR>> ><BR>> >> The easier straightforward implementation always links both pieces <BR>> >> of code in and makes a choice early in startup as to which to use, <BR>> >> either setting a boolean, or an enum, or a pointer to a record of <BR>> >> function pointers. This means that people that don't care to ever <BR>> >> use user threads pay a small price, in code bloat and probably in <BR>> >> a few extra instructions per certain functions. This is probably <BR>> >> ok.<BR>> ><BR>> > I am not so sure, since it would entail some fairly low-level and<BR>> > expensive decisions that would best instead be done at link-time.<BR>> ><BR>> >> However if that was not ok, the choice could be made at link time <BR>> >> and only be supported for standalone programs.<BR>> ><BR>> > Actually, for non-standalone (dynamically-linked) code we could make<BR>> > the choice at dynamic load time using the OS's support for dynamic<BR>> > library choice.<BR>> ><BR>> > I note that Solaris (but not Solaris Modula-3) currently lets<BR>> > dynamically linked C programs choose among 3 different threads<BR>> > implementations dynamically.<BR>> ><BR>> >><BR>> >><BR>> >> - Jay<BR>> >><BR>> >><BR>> >><BR>> >><BR>> >> CC: wagner@elegosoft.com; m3devel@elegosoft.com<BR>> >> From: hosking@cs.purdue.edu<BR>> >> To: jay.krell@cornell.edu<BR>> >> Subject: Re: [M3devel] dynamic chose between user/kernel threads?<BR>> >> Date: Thu, 8 Jan 2009 13:51:15 +1100<BR>> >><BR>> >><BR>> >> Jay, perhaps you can provide some context and motivation for your <BR>> >> proposals. I am unable to evaluate your proposals in the form of a <BR>> >> simple laundry-list.<BR>> >><BR>> >> On 8 Jan 2009, at 01:34, Jay wrote:<BR>> >><BR>> >> I looked into this a bit..and I think it's actually pretty easy.<BR>> >> It hardly churns the code even.<BR>> >><BR>> >><BR>> >> I have other things I want to do first.<BR>> >><BR>> >><BR>> >> In the meantime, specify the directive?<BR>> >> There are actually a large number of subtle options.<BR>> >><BR>> >><BR>> >> Can I ask for any of n libraries -- NT, pthreads, user threads?<BR>> >> setjmp vs. context? Or is it just a boolean, user vs. kernel?<BR>> >><BR>> >><BR>> >> Is the option to "favor" or "require" a certain library?<BR>> >><BR>> >><BR>> >> Can I set it on libraries or only programs?<BR>> >> What if the requests clash?<BR>> >><BR>> >><BR>> >> Is it "Favor" or "Require"?<BR>> >> Is it a function call or setting a global variable?<BR>> >> I favor function call, but TARGET, WORD_SIZE, BUILD_DIR establish <BR>> >> the other precedent,<BR>> >> and either can work.<BR>> >><BR>> >> Is it flags in the moduleinfo like incgc, gengc, or separate data that<BR>> >> there is just one of in RTLinker? Probably separate data, unless it <BR>> >> is allowed in libraries.<BR>> >><BR>> >><BR>> >> What are the names of the libraries?<BR>> >> "posix" and "pthreads" ?<BR>> >> "user" and "kernel" ?<BR>> >> "true" and "false" (or vice versa) ?<BR>> >><BR>> >><BR>> >> Should NT implement user threads, using fibers?<BR>> >><BR>> >><BR>> >> Presumably it works with both standalone and shared/dynamic programs.<BR>> >> Presumably it is ok to always bloat up m3core.dll with both libraries.<BR>> >> Presumably it is ok to have everyone pay a teeny tiny perf.<BR>> >> That is, there is a microscopic dispatching layer, that everyone<BR>> >> ends up going through, not chosing to link in one library or the other.<BR>> >><BR>> >><BR>> >> And as part of this, whenever it happens, can we bump up the minimum<BR>> >> bootstrap to a version that includes SchedulerPosix.DoesWaitPidYield()?<BR>> >> Or does it become VAR Scheduler.UsingKerneThreads?<BR>> >> (no, it should be a function; but naming matter remains).<BR>> >><BR>> >><BR>> >> (ie. as I said, the decision currently is baked into m3core.dll, but<BR>> >> now it is also baked into sysutils.dll, but these should change together;<BR>> >> m3core.dll should manage the knowledge).<BR>> >><BR>> >><BR>> >> - Jay<BR>> >><BR>> >><BR>> >>> Date: Sat, 3 Jan 2009 01:12:27 +0100<BR>> >>> From: wagner@elegosoft.com<BR>> >>> To: m3devel@elegosoft.com<BR>> >>> Subject: Re: [M3devel] dynamic chose between user/kernel threads?<BR>> >>><BR>> >>> An option to cm3 or a quake directive to use in the m3makefiles<BR>> >>> would suffice in my opinion (and be a great improvement).<BR>> >>><BR>> >>> Olaf<BR>> >>><BR>> >>> Quoting Jay <jay.krell@cornell.edu>:<BR>> >>><BR>> >>> ><BR>> >>> > Should the user/kernel thread chose be available:<BR>> >>> ><BR>> >>> ><BR>> >>> > On the command line to a Modula-3 executable (or even an executable<BR>> >>> > where main is in another language, but which static or dynamic<BR>> >>> > Modula-3 libs are used)?<BR>> >>> ><BR>> >>> ><BR>> >>> > Via a quake directive when building programs?<BR>> >>> ><BR>> >>> ><BR>> >>> > You know, imagine you have a bunch of Modula-3 programs and some but<BR>> >>> > not all use a very large number of threads and benefit from<BR>> >>> > userthreads.<BR>> >>> ><BR>> >>> ><BR>> >>> > Currently the chose is locked into m3core when it is built.<BR>> >>> ><BR>> >>> ><BR>> >>> > - Jay<BR>> >>><BR>> >>><BR>> >>> --<BR>> >>> Olaf<BR>> >><BR>> >><BR>> <BR>> <BR>> <BR>> -- <BR>> Olaf Wagner -- elego Software Solutions GmbH<BR>> Gustav-Meyer-Allee 25 / Geb�ude 12, 13355 Berlin, Germany<BR>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95<BR>> http://www.elegosoft.com | Gesch�ftsf�hrer: Olaf Wagner | Sitz: Berlin<BR>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194<BR>> <BR><BR></body>

</html>