<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
</style>
</head>
<body class='hmmessage'>
<BLOCKQUOTE><SPAN class=EC_Apple-style-span style="WORD-SPACING: 0px; FONT: 12px Helvetica; TEXT-TRANSFORM: none; COLOR: rgb(0,0,0); TEXT-INDENT: 0px; WHITE-SPACE: normal; LETTER-SPACING: normal; BORDER-COLLAPSE: separate">
<DIV class=EC_hmmessage style="FONT-SIZE: 10pt; FONT-FAMILY: Verdana">> [Jay] Some programs "better" with user threads</DIV>
<DIV class=EC_hmmessage style="FONT-SIZE: 10pt; FONT-FAMILY: Verdana"></SPAN>> [Tony] Is this still true for modern kernel thread systems?</DIV></BLOCKQUOTE>
<DIV> </DIV>
<DIV>I really don't know.</DIV>
Olaf /kind of/ indicated so (just in saying that it'd be a nice option to have).<BR>
<BR>
> [Jay] small stacks for many threads vs. larger stacks for calls to "the system"<BR>
<DIV> > [Tony] In a systems programming language like Modula-3 shouldn't threads have a relationship to the system?</DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV>Some might just be doing computation?</DIV>
<DIV><BR></DIV>
<BLOCKQUOTE>
<BR> > This will need to be a link-time distinction. <BR>
> I would hate to have both kernel and user thread code live in the same compiled run-time system.<BR>
<BR>
I understand the principle, and I don't have a working implementation to argue with, but I do find this surprising. In my mind, you take<BR>
MODULE ThreadPThread EXPORTS Scheduler, Thread, etc.<BR>
change it to<BR>
MODULE ThreadPThread Exports SchedulerPThread, ThreadPThread, etc.<BR>
<BR>
and introduce<BR>
MODULE Thread EXPORTS Scheduler, Thread, etc.<BR>
<BR>
PROCEDURE Fork()=<BR>
BEGIN<BR> IF KernelThreads<BR>
RETURN ThreadPThread.Fork();<BR>
ELSE<BR>
RETURN ThreadPosix.Fork();<BR></BLOCKQUOTE>
<DIV> END;</DIV>
<DIV> END Fork.</DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV> And so on. The potential bloat would be, you get both copies of code, both copies of globals, possibly initialization (but this most likely be avoided) and if any of the types are transparent, such that caller can allocate them on the stack, you end up either with the larger of the two sizes, or using a heap allocation with a dynamically chosen size.</DIV>
<DIV> It seems to be roughly one source file each of bloat.</DIV>
<DIV> </DIV>
<DIV> </DIV>
<BLOCKQUOTE>
>[Tony]I see no problem with factoring out the threads subsystem as a separate library and linking accordingly.<BR>
<BR>
That would prevent the bloat, indeed.<BR>
However, if you mean, like m3coreuserthreads.dll, m3corekernelthreads.dll, well, the vast bulk of each of those two files would be identical. You could maybe factor out m3kernelthreads.dll m3userthreads.dll out of m3core.dll and have m3core.dll dynamically chose one of them. That might be good.<BR>
<BR>
But personally..I'd like fewer .dlls, even if that means larger .dlls.<BR></BLOCKQUOTE>
<DIV><BR></DIV>
<BLOCKQUOTE>
<BR>>I would argue for user vs. kernel.<BR>
<BR>
I think you are right. Kind of like the NT386 platform argument. There are many real implementation choices, but they need not be all exposed to the user, esp. unless/until someone asks. If Cygwin pthreads made to work, and then if there are proponents of it over NT threads, and vice versa, add a switch, pick a default. In the meantime, I only made one of three options work.<BR></BLOCKQUOTE>
<DIV><BR></DIV>
<BLOCKQUOTE>
<BR>>And managing the state-space explosion that multiple choices might entail. I would like to avoid that.<BR>
<BR>
What do you mean? Growing types to the union? The globals and code bloat? Globals could all be pushed into a heap allocated pointer anyway, paying a perf cost that would unlikely be noticed.<BR>
<BR>
Again, I kind'a'thunk linking both in would be pretty ok, it's basically just one source file, but I haven't done it yet. Before I do this I need to be working on a platform with user threads, and then make them work, and then make them "switchable", and I want to bring up more platforms before I work on any user threads. AMD64_FREEBSD I think will be next.<BR></BLOCKQUOTE>
<DIV><BR></DIV>
<BLOCKQUOTE>
> I am not so sure, since it would entail some fairly low-level<BR>
> and expensive decisions that would best instead be done at link-time.<BR>
<BR>
Again this doesn't agree with my /suspicion/ but I didn't do enough research/work to be all that informed..<BR></BLOCKQUOTE>
<DIV><BR></DIV>
<BLOCKQUOTE>
> Actually, for non-standalone (dynamically-linked) code<BR>
> we could make the choice at dynamic load time using the OS's support for dynamic library choice.<BR>
<BR>
I'd rather not use dlopen et. al. at least not until I understand various details of dynamic loading across more platforms. I always though Win32 did it all just about right, and then I find a surprising array of other implementation choices and options on other systems..<BR><BR></BLOCKQUOTE>
<DIV> > I note that Solaris (but not Solaris Modula-3) currently lets</DIV>
<DIV> > dynamically linked C programs choose among 3 different threads implementations dynamically.</DIV>
<DIV><BR></DIV>
<BLOCKQUOTE><SPAN class=EC_Apple-style-span style="WORD-SPACING: 0px; FONT: 12px Helvetica; TEXT-TRANSFORM: none; COLOR: rgb(0,0,0); TEXT-INDENT: 0px; WHITE-SPACE: normal; LETTER-SPACING: normal; BORDER-COLLAPSE: separate">
<DIV class=EC_hmmessage style="FONT-SIZE: 10pt; FONT-FAMILY: Verdana">Too much of a good thing imho...</DIV>
<DIV class=EC_hmmessage style="FONT-SIZE: 10pt; FONT-FAMILY: Verdana">At least in Windows, there are a lot of "in-process plugins", and often times, interoperating code has to agree on the same underlying pieces, so wherever there is a choice, is an opportunity to fail.</DIV>
<DIV class=EC_hmmessage style="FONT-SIZE: 10pt; FONT-FAMILY: Verdana">For example, if I call malloc and give you the result to free, or I call fopen and give it to you to fwrite,</DIV>
<DIV class=EC_hmmessage style="FONT-SIZE: 10pt; FONT-FAMILY: Verdana">we need to be using the same C runtime. Even Linux has a few to chose from -- glibc, dietlibc, uclibc, newlib, etc. If you push "plugins" out of process, things become usually easier. Then folks either interoperate through carefully formatted files / pipes, network protocols, or RPC, and not via function calls.</DIV>
<DIV class=EC_hmmessage style="FONT-SIZE: 10pt; FONT-FAMILY: Verdana"> </DIV>
<DIV class=EC_hmmessage style="FONT-SIZE: 10pt; FONT-FAMILY: Verdana"> </DIV>
<DIV class=EC_hmmessage style="FONT-SIZE: 10pt; FONT-FAMILY: Verdana"> I only knew of two threading libraries on Solaris, "pre-pthreads" and "pthreads".</DIV>
<DIV class=EC_hmmessage style="FONT-SIZE: 10pt; FONT-FAMILY: Verdana">Oh, maybe "lwp" and "thr"?</DIV>
<DIV class=EC_hmmessage style="FONT-SIZE: 10pt; FONT-FAMILY: Verdana">I was wondering -- these are all built on the same kernel threads, right?</DIV>
<DIV class=EC_hmmessage style="FONT-SIZE: 10pt; FONT-FAMILY: Verdana">So if you use a mix of them in a process, you still get reasonable global scheduling, right?</DIV>
<DIV class=EC_hmmessage style="FONT-SIZE: 10pt; FONT-FAMILY: Verdana">ie: There's no point in writing ThreadSolarisThis.m3 or ThreadSolarisThat.m3, ThreadPThread.m3 suffices plenty?</DIV>
<DIV class=EC_hmmessage style="FONT-SIZE: 10pt; FONT-FAMILY: Verdana"> </DIV>
<DIV class=EC_hmmessage style="FONT-SIZE: 10pt; FONT-FAMILY: Verdana"> </DIV>
<DIV class=EC_hmmessage style="FONT-SIZE: 10pt; FONT-FAMILY: Verdana">Coming back to the bloat issue.</DIV>
<DIV class=EC_hmmessage style="FONT-SIZE: 10pt; FONT-FAMILY: Verdana">If you make the transform I show, you could also have a variant of Thread.m3 that just calls ThreadPThread.m3 directly. That is, it should be easy (still not having done it) to alter the code to build both of m3coreboth.dll and m3corejustkernel.dll. They can both have the interface that accepts the request or mandate for user threads, and m3corejustkernel.dll could either ignore or error on it.</DIV>
<DIV class=EC_hmmessage style="FONT-SIZE: 10pt; FONT-FAMILY: Verdana">Users could install one or the other .dll as m3core.dll.</DIV>
<DIV class=EC_hmmessage style="FONT-SIZE: 10pt; FONT-FAMILY: Verdana">Of course you could alos build m3corejustuser.dll.</DIV>
<DIV class=EC_hmmessage style="FONT-SIZE: 10pt; FONT-FAMILY: Verdana">(These are stupid names, I know.)</DIV>
<DIV class=EC_hmmessage style="FONT-SIZE: 10pt; FONT-FAMILY: Verdana"> </DIV>
<DIV class=EC_hmmessage style="FONT-SIZE: 10pt; FONT-FAMILY: Verdana">I really need to try it and see, it's fairly hypothetical right now.</DIV>
<DIV class=EC_hmmessage style="FONT-SIZE: 10pt; FONT-FAMILY: Verdana">It sounds like I might be missing something.</DIV>
<DIV class=EC_hmmessage style="FONT-SIZE: 10pt; FONT-FAMILY: Verdana">But first some other things..</DIV>
<DIV class=EC_hmmessage style="FONT-SIZE: 10pt; FONT-FAMILY: Verdana"><BR> - Jay<BR><BR><BR><BR></DIV>
<DIV class=EC_hmmessage style="FONT-SIZE: 10pt; FONT-FAMILY: Verdana">
<HR id=EC_stopSpelling>
</DIV>
<DIV class=EC_hmmessage style="FONT-SIZE: 10pt; FONT-FAMILY: Verdana"><BR>CC:<SPAN class=EC_Apple-converted-space> </SPAN><A href="mailto:wagner@elegosoft.com">wagner@elegosoft.com</A>;<SPAN class=EC_Apple-converted-space> </SPAN><A href="mailto:m3devel@elegosoft.com">m3devel@elegosoft.com</A><BR>From:<SPAN class=EC_Apple-converted-space> </SPAN><A href="mailto:hosking@cs.purdue.edu">hosking@cs.purdue.edu</A><BR>To:<SPAN class=EC_Apple-converted-space> </SPAN><A href="mailto:jay.krell@cornell.edu">jay.krell@cornell.edu</A><BR>Subject: Re: [M3devel] dynamic chose between user/kernel threads?<BR>Date: Thu, 8 Jan 2009 13:51:15 +1100<BR><BR><BR></DIV>
<DIV class=EC_hmmessage style="FONT-SIZE: 10pt; FONT-FAMILY: Verdana">Jay, perhaps you can provide some context and motivation for your proposals. I am unable to evaluate your proposals in the form of a simple laundry-list.</DIV>
<DIV class=EC_hmmessage style="FONT-SIZE: 10pt; FONT-FAMILY: Verdana"><BR></DIV>
<DIV class=EC_hmmessage style="FONT-SIZE: 10pt; FONT-FAMILY: Verdana">
<DIV>On 8 Jan 2009, at 01:34, Jay wrote:</DIV><BR class=EC_EC_Apple-interchange-newline>
<BLOCKQUOTE><SPAN class=EC_EC_Apple-style-span style="WORD-SPACING: 0px; FONT: 12px Helvetica; TEXT-TRANSFORM: none; COLOR: rgb(0,0,0); TEXT-INDENT: 0px; WHITE-SPACE: normal; LETTER-SPACING: normal; BORDER-COLLAPSE: separate">
<DIV class=EC_EC_hmmessage style="FONT-SIZE: 10pt; FONT-FAMILY: Verdana">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 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 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:<SPAN class=EC_EC_Apple-converted-space> </SPAN><A href="mailto:wagner@elegosoft.com">wagner@elegosoft.com</A><BR>> To:<SPAN class=EC_EC_Apple-converted-space> </SPAN><A href="mailto:m3devel@elegosoft.com">m3devel@elegosoft.com</A><BR>> Subject: Re: [M3devel] dynamic chose between user/kernel threads?<BR>><SPAN class=EC_EC_Apple-converted-space> </SPAN><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>><SPAN class=EC_EC_Apple-converted-space> </SPAN><BR>> Olaf<BR>><SPAN class=EC_EC_Apple-converted-space> </SPAN><BR>> Quoting Jay <<A href="mailto:jay.krell@cornell.edu">jay.krell@cornell.edu</A>>:<BR>><SPAN class=EC_EC_Apple-converted-space> </SPAN><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<SPAN class=EC_EC_Apple-converted-space> </SPAN><BR>> > where main is in another language, but which static or dynamic<SPAN class=EC_EC_Apple-converted-space> </SPAN><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<SPAN class=EC_EC_Apple-converted-space> </SPAN><BR>> > not all use a very large number of threads and benefit from<SPAN class=EC_EC_Apple-converted-space> </SPAN><BR>> > userthreads.<BR>> ><BR>> ><BR>> > Currently the chose is locked into m3core when it is built.<BR>> ><BR>> ><BR>> > - Jay<BR>><SPAN class=EC_EC_Apple-converted-space> </SPAN><BR>><SPAN class=EC_EC_Apple-converted-space> </SPAN><BR>> --<SPAN class=EC_EC_Apple-converted-space> </SPAN><BR>> Olaf<BR></DIV></SPAN></BLOCKQUOTE></DIV>
<DIV class=EC_hmmessage style="FONT-SIZE: 10pt; FONT-FAMILY: Verdana"><BR></DIV></SPAN><BR class=EC_Apple-interchange-newline></BLOCKQUOTE><BR></body>
</html>