Re: [TCLCORE] about TIP #304 + #301

[Alexandre F. <ale...@gm...>]

On 2/26/07, Andreas Leitgeb <av...@lo...> wrote:
> On Sat, Feb 24, 2007 at 10:44:20PM +0100, Alexandre Ferrieux wrote:
> >
> > My preference for this would be a separate [waitpid $pid], rather than
> > an artificial "binding" between the standalone pipe and a specific
> > child.
>
> A separate [waitpid] isn't it, either.  It would mean that
> the GUI is dead while waiting for the process to finish.
> (this is, of course, already the case for [close], but in that case
> the close is generally called, when in the fileevent-handler
> eof is already reached, and where end-of-process can generally be
> expected to have already occurred.)

Okay, but blocking calls already exist, and it has always been the
programmer's responsibility to avoid lingering too long outside the
event loop (if any).
And as long as you use [waitpid $pid] just after getting an EOF,
you're exactly displaying the same blocking behavior as [close] does
today (i.e. it may freeze your GUI if the child happens to close its
stdout long before exiting).

Now you're digging up the idea of async SIGCHLD (et al) notification.
AFAIK signal handlers have always been kept away from Tcl (but inTclX)
mainly because they're unavailable in Windows. I'm agnostic about
this, but the bottom line is that currently it seems simpler to add a
blocking primitive [waitpid] than an entirely new event source with
portability issues.

Moreover, in current Tcl you can always be notified of a non-writing
child's fate, simply by registering a fileevent on its (unused)
stdout. Even in Windows...

-Alex