<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
</style>
</head>
<body class='hmmessage'>
Perhaps, tangentially, we should strive to reduce stack usage in Trestle?<BR>
Not as an alternative, granted.<BR>
<BR>
- Jay<BR><BR><BR>
<HR id=stopSpelling>
<BR>
Date: Fri, 2 Jan 2009 16:18:40 -0500<BR>From: rcoleburn@scires.com<BR>To: m3devel@elegosoft.com<BR>Subject: Re: [M3devel] FW: variations of waitpid..?<BR><BR><BR>
<STYLE>
.ExternalClass .EC_hmmessage P
{padding:0px;}
.ExternalClass body.EC_hmmessage
{font-size:10pt;font-family:Verdana;}
</STYLE>
<DIV>Jay:</DIV>
<DIV> </DIV>
<DIV>Your comment about stack size rang a bell with me.</DIV>
<DIV> </DIV>
<DIV>I have had trouble in the past running out of stack space, most notably on HP-UX. Same program built on Windows usually did not suffer the same fate. I seem to recall the most stack space trouble was when a thread did anything with Trestle/FormsVBT etc.</DIV>
<DIV> </DIV>
<DIV>So, I added a command line switch to my program that let's you specify a multiplier for the stack size. During initialization, my programs read the command line switches and take appropriate action to increase the thread stack sizes before any threads are created.</DIV>
<DIV> </DIV>
<DIV>If you don't specify a stack size multiplier on the command line, I think I wound up using seven (7) as the default.</DIV>
<DIV> </DIV>
<DIV>Here is a code excerpt:</DIV>
<DIV> IF stackMult > 1<BR> THEN<BR> WITH default = Thread.GetDefaultStackSize(),<BR> desired = default * stackMult,<BR> increase = desired - default<BR> DO<BR> PutText("Increasing default stack size by a factor of " &<BR> Fmt.Int(stackMult) & " (" & Fmt.Int(default) & " >>> " &<BR> Fmt.Int(desired) & ").\n");<BR> Thread.IncDefaultStackSize(increase);<BR> END; (* with *)<BR> WITH default = Thread.GetDefaultStackSize()<BR> DO<BR> PutText("Thread stacks are now " & Fmt.Int(default) & " bytes.\n");<BR> END; (* with *)<BR> END; (* if *)<BR></DIV>
<DIV>Regards,</DIV>
<DIV>Randy</DIV>
<DIV><BR>>>> Jay <jay.krell@cornell.edu> 12/31/2008 8:59 PM >>><BR>[truncated just slightly..and probably will be again given more rambling..]<BR> <BR>ps: the internal use in m3core could be easily removed, just by compiling one branch of the if or the other.<BR>I just wanted them in the same file to keep similar code closer together.<BR> <BR>So it comes down that m3core does expose Uwaitpid.waitpid and Uexec.waitpid, and as long as they are...or as long as user threads exist..imho there is some obligation of m3core to expose perhaps surprising characteristics of its thread library. You might say the entire interface is already and has always been fully exposed in Thread.i3, but I don't believe it. User threads and kernel threads have too divergent too visible artifacts, that I don't think are previously exposed in the public interface.<BR> <BR>I claim it is somewhat "surprising", or at least important to know the detail of, whether or not waitpid yields to other threads.<BR> <BR>You know, I mean..let's say I am some really clever waitpid user and I really must use it. And I am using Modula-3 threads. And my child process is reading the output of Modula-3 threads. Aren't I kind of stuck? Isn't there /some/ obligation of m3core to help just a teeny tiny bit? Or, would you argue, I am obligated, if I am using Modula-3, to use the higher level interfaces, that already know about this? Well, ok, m3core did already know about, I fixed it only a few months ago, but then even the likes of sysutils is stuck?<BR> <BR>Another example, that may or may not be well exposed, is willingness/ability to set thread stack size. Mika mentions creation thousands of threads. 32bit kernel threads are going to be more limited here. Whereas 32bit user threads might be willing to create much smaller stacks, and 64 bit anything has essentially infinite address space for infinite stacks (but still beware working set, physical memory is not infinite).<BR> <BR>(Personally I have seen precious little code that cares about stack size, just seems to somehow get along, combined with the fact that the current Modula-3 pthread code very likely leaks on some platforms attempting to deal with stack size, makes me inclined to just rip out the code..but yeah..just fix the leak...)<BR> <BR> - Jay<BR><BR></DIV>
<DIV>
<HR id=EC_stopSpelling>
</DIV>
<DIV><BR>From: jay.krell@cornell.edu<BR>To: hosking@cs.purdue.edu<BR>CC: mika@async.caltech.edu; m3devel@elegosoft.com<BR>Subject: RE: [M3devel] variations of waitpid..?<BR>Date: Thu, 1 Jan 2009 01:49:28 +0000<BR><BR>
<STYLE>
.ExternalClass .EC_hmmessage P
{padding:0px;}
.ExternalClass body.EC_hmmessage
{font-size:10pt;font-family:Verdana;}
</STYLE>
> If someone uses waitpid they get what they paid for. <BR> <BR>But someone is us -- m3core/libm3 (I think just m3core), sysutils, and then cm3 uses them.<BR> <BR>I guess there is a point that this "grand new interface" SchedulerPosix.DoesWaitPidYield has precious few users.<BR> (It isn't grand. It takes no parameters and just returns a boolean, hardcoded, depending on thread library.)<BR> <BR>m3core now (today) uses it internally -- no need for a public interface.<BR>Sysutils can't use it until the baseline m3core is newer, so arguably, not a user.<BR> Instead (today) sysutils uses m3core's m3makefiles to decide the value.<BR> <BR>Heck, waitpid is therefore only used internally by m3core, and sysutils.<BR>If sysutils could be (partly) merged into m3core, then m3core's waitpid need not be public.<BR> <BR> - Jay<BR><BR>> CC: mika<BR>> From: hosking<BR>> To: jay<BR>> Subject: Re: [M3devel] variations of waitpid..?<BR>> Date: Thu, 1 Jan 2009 12:29:24 +1100<BR>> <BR>> If someone uses waitpid they get what they paid for.<BR><BR></DIV></body>
</html>