<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
</style>
</head>
<body class='hmmessage'>
I didn't read that well -- the deadlock risk in sysutils is not there.<BR>
The bad perf is probably.<BR>
<BR>
<BR>
To be clear (esp. for folks that might not already know about this,<BR>
I didn't know about until fairly recently), there are two options:<BR>
<BR>
<BR>
waitpid(pid, flags = 0)<BR>
move along<BR>
<BR>
<BR>
or<BR>
while (waitpid(pid, flags = nohang) != 0)<BR>
sleep(some value)<BR>
<BR>
<BR>
The second is what sysutils was doing, and works, doesn't deadlock, is deoptimized.<BR>
m3core/libm3 did this for a long time as well. When I complained about perf, it was pointed out to me.<BR>
<BR>
The first has deadlock potential with userthreads, but is ok and faster with kernel threads.<BR>
<BR>
<BR>
waitpid(flags = nohang = don't actually wait, just get the exit code, if there is one) is a way to quickly poll if a process has ended, and if so, get its exit code. In Win32 there are two seperate functions GetExitCodeProcess and WaitForSingleObject or WaitForMultipleObjects ("waiting" is generalized across files, processes, sockets, files, threads, semaphores, mutexes, events and more..but not critical sections..only kernel objects). These have a bug too. One particular exit code is reserved to mean "the process is still running", but that is easily avoided by using Wait first. I have seen code get confused by this though. Wait also accepts a timeout, 32bit unsigned milliseconds, including 0 and infinity, so also can be used to poll. Win32 also defines the exit code to be 32bits, whereas Posix only allows for 8 bits which can be an interop problem. Perl on Win32 truncates exit codes to 8 bits, very bad. Unhandled exceptions end up as "large" exit codes.<BR>
<BR>
Anyway...<BR>
<BR>
The problem with the polling approach, at least part of the problem, is that if the child process isn't done when waitpid is first called, but finishes before sleep(whatever value) ends, we will still sleep for the full "whatever value". You only really want to sleep until the child process is done, and no longer.<BR>
<BR>
<BR>
Making just the first sleep shorter might be a good idea.<BR>
You know, to handle processes that are short-lived, but not "zero" lived.<BR>
("zero" being the amount of time it takes for the code to proceed from fork/exec to waitpid, surely much smaller than a small sleep() but longer than no sleep).<BR>
<BR>
<BR>
Calling just waitpid(flags = 0) could deadlock if, for example, a parent thread is writing to a child's stdin, and the child won't finish until the parent has written all that it needs to. The parent and child process, er, other threads in the parent process, need to be allowed to run concurrently, for the sake of at least some reasonable scenarios.<BR>
<BR>
With kernelthreads, the implementation of waitpid knows about threads and will itself, in a sense, do the poll/sleep, but not exactly that -- it won't sleep beyond the child process finishing.<BR>
<BR>
<BR>
Hopefully this makes sense and lets more folks understand the problem.<BR>
<BR>
<BR>
What you can do, of course, is like:<BR>
<BR>
<BR>
if kernelthreads<BR>
waitpid(flags = 0)<BR>
else<BR>
while (waitpid(flags = nohang) != 0)<BR>
sleep<BR>
<BR>
<BR>
and that is basically what the code looks like now.<BR>
<BR>
The part "if kernelthreads" I propose be "if SchedulerPosix.DoesWaitPidYield()"<BR>
though a really direct "if Thread or Scheduler.KernelThreads" might be reasonable.<BR>
Up to folks then to decide what that implies..<BR>
<BR>
- Jay<BR><BR><BR>> Date: Fri, 2 Jan 2009 11:27:24 +0100<BR>> From: wagner@elegosoft.com<BR>> To: m3devel@elegosoft.com<BR>> Subject: Re: [M3devel] variations of waitpid..?<BR>> <BR>> Quoting Tony Hosking <hosking@cs.purdue.edu>:<BR>> <BR>> > If someone uses waitpid they get what they paid for.<BR>> It is so long ago that we wrote those sysutils routines...<BR>> They have only ever be used in simple command line utilities (like cm3)<BR>> without much concurrency, I think. If there is potential for deadlocks<BR>> and bad performance, we should at least document that in the interfaces.<BR>> <BR>> I am not up-to-date wrt. the M3 system interfaces and threads<BR>> implementation: is there a way for a thread to wait for the exit code<BR>> of another process without blocking other threads? If so, I'll adapt<BR>> the sysutils code... If not, can we introduce such an interface in<BR>> m3core/libm3?<BR>> <BR>> Olaf<BR>> <BR>> > On 1 Jan 2009, at 06:24, Jay wrote:<BR>> ><BR>> >><BR>> >> You mean, this function is easy to misuse?<BR>> >>> People who declare their own <*EXTERNAL*><BR>> >> Like waitpid exposed from m3core?<BR>> >><BR>> >> waitpid is already easy to misuse, on a userthread system, leading <BR>> >> to possible (though I think rare) deadlock.<BR>> >> It is easy to misuse on pthreads, lead "just" to bad performance, <BR>> >> 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 <BR>> >> perf of cm3/sysutils.<BR>> >><BR>> >> On a userthread system, waitpid(pid, flags = 0) waits for the child <BR>> >> process, with all parent threads suspended.<BR>> >> Generally I doubt the child depends on parent threads progressing, <BR>> >> but, yeah, that could deadlock, like if a parent thread is waiting <BR>> >> 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 <BR>> >> try again.<BR>> >><BR>> >> pthreads just uses waitpid(pid, flags = 0) and all threads keep running<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>