<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
</style>
</head>
<body class='hmmessage'>
> 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><BR>
Yes, by using kernel threads (which is all that work currently, but I'll probably fix that..)<BR>
If you know you are using kernel threads, you can optimize accordingly.<BR>
I measured the difference when I fixed m3core/libm3 and it was significant, though I forgot the details (they should be in the m3commit or m3devel history).<BR>
I didn't measure for sysutils.<BR>
<BR>
<BR>
It seems to me that sysutils provides /roughly/ but not exactly identical abstractions as m3core/libm3.<BR>
This is not "bad", it just means m3core/libm3 aren't necessarily providing the best, sufficiently general abstractions. That happens. (It is also common for folks to reimplement stuff due to not understanding what is available, or there being a real or perceived inability to change what is available.) For this reason, that I fixed m3core/libm3 months ago, does not help sysutils. That is, sysutils uses waitpid, and the waitpid uses in m3core/libm3 are "buried" in higher abstractions.<BR>
<BR>
<BR>
m3core/waitpid itself, I think, is not where this fix belongs.<BR>
But maybe.<BR>
I think that would change its semantics too much, even if its semantics are problematic.<BR>
Maybe. I hadn't considered this. At least the change would only be in the user threads implementation. Everyone could perhaps just pass 0, and a wrapper would change to nohang and poll/sleep loop.<BR>
pthreads would not -- it'd just pass on directly through.<BR>
<BR>
<BR>
A lower level interface is needed for sysutils, and I added one.<BR>
I added SchedulerPosix.DoesWaitPidYield.<BR>
It just returns true for pthreads and false for userthreads.<BR>
<BR>
However, I believe sysutils cannot take on new m3core/libm3 dependencies, unless the minimum version for bootstrapping is raised, to a version that includes those changes.<BR>
Therefore I don't use the very abstraction provided to solve the problem, but something similar.<BR>
The code is now prepared to trivially switch to it, when the time comes that the minimum m3core/libm3 is raised.<BR>
<BR>
<BR>
Similar story as the portable waitpid C wrapper, which I think fixes errors on I386_DARWIN and AMD64_DARWIN, though that I think only matters if a process returns non-zero, was ok for returning 0.<BR>
There the code is well shared, but via automated copy and rename.<BR>
<BR>
<BR>
For waitpid, I changed the "copied abstraction" to just be an interace containing a constant, instead of a function call. Perhaps a constant in m3core would be appropriate too.<BR>
However..I wonder if the user/kernel threads option should be chosable at runtime or the command line or the default changable when building executables, all using the same runtime that could support either, therefore a function call. I know, it isn't chosable as such currently, it is a feature of the m3core as-built, but maybe a nice idea.<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>