<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
</style>
</head>
<body class='hmmessage'>
You mean, this function is easy to misuse?<BR>
<BR> > People who declare their own <*EXTERNAL*><BR><BR>
Like waitpid exposed from m3core?<BR>
 <BR>
waitpid is already easy to misuse, on a userthread system, leading to possible (though I think rare) deadlock.<BR>
It is easy to misuse on pthreads, lead "just" to bad performance, and in fact I believe cm3 is doing this, via sysutils.<BR>
This at least guides you between two patterns of use, and fix the perf of cm3/sysutils.<BR>
 <BR>
On a userthread system, waitpid(pid, flags = 0) waits for the child process, with all parent threads suspended.<BR>
Generally I doubt the child depends on parent threads progressing, but, yeah, that could deadlock, like if a parent thread is waiting to a file or stdin of the child, or reading a child's stdout.<BR>
 <BR>
The various uses do waitpid(pid, flags = nohang) and then sleep and try again.<BR>
 <BR>
pthreads just uses waitpid(pid, flags = 0) and all threads keep running.<BR>
Win32 just uses WaitForSingleObject(process handle, timeout=infinite), and again all threads keep running.<BR>
 <BR>
Just another problem with user threads, where pthreads and Win32 are fine.<BR>
 <BR>
> >PROCEDURE Scheduler.DoesWaitProcessYield() : BOOLEAN?<BR><BR>
WaitPROCESS always yields.<BR>
It is WaitPID that may or may not.<BR>
So I renamed the function to DoesWaitPidYield() and moved it to SchedulerPosix.i3.<BR>
 <BR>
ok?<BR>
 <BR>
 - Jay<BR><BR><BR>> To: jay.krell@cornell.edu<BR>> CC: m3devel@elegosoft.com<BR>> Subject: Re: [M3devel] variations of waitpid..? <BR>> Date: Tue, 30 Dec 2008 23:22:41 -0800<BR>> From: mika@async.caltech.edu<BR>> <BR>> <BR>> I don't think it should be possible to stop other threads if the<BR>> runtime could even conceivably support an environment where that's<BR>> not necessary. You're introducing dependencies that will lead to<BR>> (undetectable) deadlocks. People who declare their own <*EXTERNAL*><BR>> things are, as usual, on their own.<BR>> <BR>> Mika<BR>> <BR>> Jay writes:<BR>> ><BR>> >Hm. How about:<BR>> > <BR>> >PROCEDURE Scheduler.DoesWaitProcessYield() : BOOLEAN?<BR>> > <BR>> >?<BR>> >true for pthreads/win32/cygwin<BR>> >false for userthreads<BR>> > <BR>> >duplicated privately in sysutils to avoid depending on newer m3core<BR>> > like I did for the portable C-wrapped waitpid<BR>> > <BR>> >?<BR>> > <BR>> >That way..the other code can do whatever it already is doing,<BR>> >no need to come up with abstractions for looping with nohang,<BR>> >vs. that plus the status loophole.<BR>> > <BR>> >The older fix I put it can be shrunk.<BR>> > <BR>> >The name of this is debatable, but I think the minimal level of abstraction is<BR>> > goodness.<BR>> > <BR>> >The name is actually perhaps too..complicated..like, what does it mean?<BR>> >Who uses it? What do they do with it?<BR>> > <BR>> >It means that waiting on a process to end allows threads in the waiting proces<BR>> >s to run.<BR>> >Perhaps it is too low level.<BR>> > <BR>> > <BR>> > - Jay<BR>> ><BR>> ><BR>> ><BR>> >----------------------------------------<BR>> >> From: jay.krell@cornell.edu<BR>> >> To: m3devel@elegosoft.com<BR>> >> Date: Wed, 31 Dec 2008 05:33:22 +0000<BR>> >> Subject: [M3devel] variations of waitpid..?<BR>> >><BR>> >><BR>> >> variations of waitpid..<BR>> >><BR>> >> Hey, we already have, that I put in on my initiative, months ago:<BR>> >><BR>> >> C:\dev2\cm3.2\m3-libs\m3core\src\thread\POSIX\ThreadPosix.m3<BR>> >><BR>> >> PROCEDURE WaitProcess (pid: int): int =<BR>> >> (* ThreadPThread.m3 and ThreadPosix.m3 are the same here except ThreadPosix.<BR>> >m3 calls Pause(). *)<BR>> >> VAR<BR>> >> result: int;<BR>> >> statusM3: Uwaitpid.waitpid_status_t;<BR>> >> CONST Delay = 0.1D0;<BR>> >> BEGIN<BR>> >> LOOP<BR>> >> result := Uwaitpid.waitpid(pid, statusM3, Uwaitpid.WNOHANG);<BR>> >> IF result # 0 THEN EXIT END;<BR>> >> Pause(Delay);<BR>> >> END;<BR>> >> 0 *><BR>> >> RETURN statusM3.w_Loophole;<BR>> >> END WaitProcess;<BR>> >><BR>> >> pthreads and cygwin:<BR>> >><BR>> >> C:\dev2\cm3.2\m3-libs\m3core\src\thread\WIN32\WaitProcessCygwin.m3<BR>> >> and<BR>> >> C:\dev2\cm3.2\m3-libs\m3core\src\thread\PTHREAD\ThreadPThread.m3<BR>> >><BR>> >> PROCEDURE WaitProcess (pid: int): int =<BR>> >> (* ThreadPThread.m3 and ThreadPosix.m3 are very similar. *)<BR>> >> VAR<BR>> >> statusM3: Uwaitpid.waitpid_status_t;<BR>> >> BEGIN<BR>> >> LOOP<BR>> >> WITH r = Uwaitpid.waitpid(pid, statusM3) DO<BR>> >> IF r> 0 THEN<BR>> >> RETURN statusM3.w_Loophole;<BR>> >> END;<BR>> >> < 0*><BR>> >> END;<BR>> >><BR>> >> END;<BR>> >> END WaitProcess;<BR>> >><BR>> >> win32:<BR>> >> PROCEDURE WaitProcess (pid: int): int =<BR>> >> BEGIN<BR>> >><BR>> >> RETURN 0;<BR>> >> END WaitProcess;<BR>> >><BR>> >> ThreadPThread and WaitProcessCygwin should share code, but that's not the po<BR>> >int.<BR>> >><BR>> >> However, now, to fix sysutils, we need something LIKE:<BR>> >><BR>> >> UNSAFE INTERFACE SystemPosixWaitPid;<BR>> >> FROM Ctypes IMPORT int;<BR>> >> FROM Sysutils_Uwaitpid IMPORT waitpid_status_t;<BR>> >> FROM Utypes IMPORT pid_t;<BR>> >><BR>> >> PROCEDURE WaitPid(pid: pid_t; VAR status: waitpid_status_t): int;<BR>> >><BR>> >> BEGIN<BR>> >> END SystemPosixWaitPid.<BR>> >><BR>> >> pthreads:<BR>> >><BR>> >> UNSAFE MODULE SystemPosixWaitPidEfficient EXPORTS SystemPosixWaitPid;<BR>> >><BR>> >> FROM Ctypes IMPORT int;<BR>> >> FROM Sysutils_Uwaitpid IMPORT waitpid_status_t, waitpid;<BR>> >> FROM Utypes IMPORT pid_t;<BR>> >><BR>> >> PROCEDURE WaitPid(pid: pid_t; VAR status: waitpid_status_t): int =<BR>> >> BEGIN<BR>> >> RETURN waitpid(pid, status, 0);<BR>> >> END WaitPid;<BR>> >><BR>> >> BEGIN<BR>> >> END SystemPosixWaitPidEfficient.<BR>> >><BR>> >> user threads:<BR>> >><BR>> >> UNSAFE MODULE SystemPosixWaitPidPause EXPORTS SystemPosixWaitPid;<BR>> >><BR>> >> FROM Ctypes IMPORT int;<BR>> >> FROM Sysutils_Uwaitpid IMPORT waitpid_status_t, waitpid;<BR>> >> FROM Utypes IMPORT pid_t;<BR>> >><BR>> >> PROCEDURE WaitPid(pid: pid_t; VAR status: waitpid_status_t): int =<BR>> >> VAR result: int;<BR>> >> CONST Delay = 0.1D0;<BR>> >> BEGIN<BR>> >> LOOP<BR>> >> result := waitpid(pid, status, Sysutils_Uwaitpid.WNOHANG);<BR>> >> IF result # 0 THEN<BR>> >> EXIT<BR>> >> END;<BR>> >> Thread.Pause(Delay)<BR>> >> END;<BR>> >> END WaitPid;<BR>> >><BR>> >> BEGIN<BR>> >> END SystemPosixWaitPidPause.<BR>> >><BR>> >> questions:<BR>> >><BR>> >> Aside: Where do I put "unsafe"?<BR>> >><BR>> >> Relevant: Sysutils has to implement this itself, right?<BR>> >> Due to bootstrapping concerns.<BR>> >><BR>> >> But we should still put /something/ in m3core, right?<BR>> >><BR>> >> So then the big question, what to call it?<BR>> >><BR>> >> Probably, the existing WaitProcess that does more than this WaitPid, should <BR>> >be scaled<BR>> >> back and only do what WaitPid does?<BR>> >><BR>> >> I will likely commit exactly what is shown above.<BR>> >> The new interface and modules are in sysutils. The interface is private.<BR>> >><BR>> >> The unfinished part is putting something in m3core, that sysutils could use,<BR>> > if<BR>> >> not for boostrapping issuers, that it could use in the future.<BR>> >><BR>> >> I kind of thing something a bit more is needed.<BR>> >> You know, the Win32 implementation that asserts(false) is suspicious.<BR>> >> At the very least, it should be removed.<BR>> >><BR>> >> I suspect I am missing something though, as suggested by Win32 having an ass<BR>> >ert(false) implementation.<BR>> >> Either that needs to be removed, or somehow the code can be unified, using j<BR>> >ust the existing m3core/libm3<BR>> >> interfaces?<BR>> >><BR>> >> I also suspect part of the problem is that sysutils implements to a large ex<BR>> >tent<BR>> >> the same abstractions as m3core and/or libm3, but with variations, causing i<BR>> >t to be unable<BR>> >> to build on what is there, but having to reinvent..which suggests the m3core<BR>> >/libm3 abstractions<BR>> >> maybe are not general/featureful enough.<BR>> >><BR>> >> (Btw, unstated above, is that sysutils/m3makefile will have the same sort of<BR>> > switch as m3core does, wrt if it builds for user/alaram threads or kernel/pth<BR>> >reads.)<BR>> >><BR>> >><BR>> >> ??<BR>> >><BR>> >> - Jay<BR><BR></body>
</html>