Re: [TCLCORE] TIP #462 : Request For Comments

----- Mail original -----
> De: "Andreas Leitgeb" <a...@logic.at>> Thanks for that example.  It raises a new question, though:> > % tcl::process autopurge 0> % exec <some command that fails>> child process exited abnormally> % tcl::process autopurge 1> % exec <some command that fails>> child process exited abnormally> > at this point, which of the two exec-invocations' status is> available?>   a) the former ("because status was kept while autopurge was 0")>   b) none ("because autopurge was 1 at the second exec, and it>                cleaned everything up")>   c) other outcomes seem unlikely to me, but who knows...> > If we look at a command pipe, would autopurge need to be 0 at time> of start or of close, or both  to retain the information?

An undocumented side effect of [tcl::process (list|status)] is that they purge terminated processes automatically when autopurge is on, because only active pids/statuses are returned (this is by design). So the answer is mostly b) but the TIP certainly needs clarification on this point to understand why. Here is an example to illustrate:

###### status.tcl (prints the PID then returns its first argument as a status code)
puts [pid]
exit {*}$argv
######

###### tclsh console
% # Disable autopurge
% tcl::process autopurge 0
0
% # Child with normal exit status
% exec tclsh status.tcl 0
9212
% # Child with abnormal exit status
% exec tclsh status.tcl 1
18268
child process exited abnormally
% # Query status: Both children are available
% tcl::process status
9212 0 18268 {1 {child process exited abnormally} {CHILDSTATUS 18268 1}}
%
% # Enable autopurge temporarily
% tcl::process autopurge 1
1
% # Disable autopurge immediately afterward
% tcl::process autopurge 0
0
% # Query status again: Both children are still available
% tcl::process status
9212 0 18268 {1 {child process exited abnormally} {CHILDSTATUS 18268 1}}
%
% # Enable autopurge for good this time
% tcl::process autopurge 1
1
% # Query status : empty result because terminated children are purged in the process (pun not intended)
% tcl::process status
%
% # Child with autopurge enabled
% exec tclsh status.tcl 1
17292
child process exited abnormally
% # Query status : result was purged
% tcl::process status
%


> > > De: "Andreas Leitgeb" <a...@logic.at>> > > Some time ago, someone had a problem, where he opened a> > > process-pipe,> > > and the started process itself forked passing its stdout to its> > > own> > > childprocess and then exiting itself.> > > > > > With the new machinery of tip 462, would one be more flexible> > > about> > > handling the "termination" of the pipe separately from the> > > termination> > > of the child process?> > No idea honestly.> > An attempt to clarify my question: when I open a command pipe, then> (ignoring the normal cases) there are two particular *special* cases> possible at the end:> >   a) the process closed its stdout, but doesn't exit yet> >   b) the process has exited, but the pipe is still open>        (because of a "grandchild" still running and holding>        the pipe open)> > The questions are now:> >  in case a)>     Is it possible to close the pipe (clean up the channel)>     explicitly without waiting for the process?> >  in case b)>     Is it possible to query the exit status of the process,>     even though the pipe is still active.  If at a later time>     the pipe gets closed by the pipe's last remaining peer,>     what status would close report lateron, when the direct>     child's status has meanwhile been queried/consumed by a>     call to tcl::process status?> > > - no changes were made to the way Tcl manages process pipes, so if> > the> > behavior you describe is still present in the core then the TIP has> > no> > effect on it.> > At least when autopurge is set to 0, there has to be some change, or> any> information would be lost by the time it's queried...> > I didn't intend to use the process command to query the grandchild.> I mentioned it merely that it might exist and keep the pipe open> at the time the direct child exits.

I'll do the test (BTW if you have an example script I'll be happy to test it as well) just to check that everything behaves the same in both autopurge on/off situations. I believe it should, because the implementation makes no change to the way Tcl handles theses cases already, besides recording the status in a separate structure of course (and it does so from the place where Tcl already detects pipe closure/child process termination: the error info returned to the caller is also stored for latter consumption when autopurge is off).

Do you know if there are existing test cases in the Tcl test suite that cover these use cases?

Fred

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Tcl-Core mailing list
Tcl-...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tcl-core