[M3devel] variations of waitpid..?

[Jay]

> is there a way for a thread to wait for the exit code> of another process without blocking other threads? If so, I'll adapt
Yes, by using kernel threads (which is all that work currently, but I'll probably fix that..)
If you know you are using kernel threads, you can optimize accordingly.
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).
I didn't measure for sysutils.
 
 
It seems to me that sysutils provides /roughly/ but not exactly identical abstractions as m3core/libm3.
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.
 
 
m3core/waitpid itself, I think, is not where this fix belongs.
But maybe.
I think that would change its semantics too much, even if its semantics are problematic.
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.
pthreads would not -- it'd just pass on directly through.
 
 
A lower level interface is needed for sysutils, and I added one.
I added SchedulerPosix.DoesWaitPidYield.
It just returns true for pthreads and false for userthreads.
 
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.
Therefore I don't use the very abstraction provided to solve the problem, but something similar.
The code is now prepared to trivially switch to it, when the time comes that the minimum m3core/libm3 is raised.
 
 
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.
There the code is well shared, but via automated copy and rename.
 
 
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.
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.
 
 - Jay> Date: Fri, 2 Jan 2009 11:27:24 +0100> From: wagner at elegosoft.com> To: m3devel at elegosoft.com> Subject: Re: [M3devel] variations of waitpid..?> > Quoting Tony Hosking <hosking at cs.purdue.edu>:> > > If someone uses waitpid they get what they paid for.> It is so long ago that we wrote those sysutils routines...> They have only ever be used in simple command line utilities (like cm3)> without much concurrency, I think. If there is potential for deadlocks> and bad performance, we should at least document that in the interfaces.> > I am not up-to-date wrt. the M3 system interfaces and threads> implementation: is there a way for a thread to wait for the exit code> of another process without blocking other threads? If so, I'll adapt> the sysutils code... If not, can we introduce such an interface in> m3core/libm3?> > Olaf> > > On 1 Jan 2009, at 06:24, Jay wrote:> >> >>> >> You mean, this function is easy to misuse?> >>> People who declare their own <*EXTERNAL*>> >> Like waitpid exposed from m3core?> >>> >> waitpid is already easy to misuse, on a userthread system, leading > >> to possible (though I think rare) deadlock.> >> It is easy to misuse on pthreads, lead "just" to bad performance, > >> and in fact I believe cm3 is doing this, via sysutils.> >> This at least guides you between two patterns of use, and fix the > >> perf of cm3/sysutils.> >>> >> On a userthread system, waitpid(pid, flags = 0) waits for the child > >> process, with all parent threads suspended.> >> 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.> >>> >> The various uses do waitpid(pid, flags = nohang) and then sleep and > >> try again.> >>> >> pthreads just uses waitpid(pid, flags = 0) and all threads keep running> > > > -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Gebäude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95> http://www.elegosoft.com | Geschäftsführer: Olaf Wagner | Sitz: Berlin> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20090102/6460dd3c/attachment-0002.html>