TIP:            88
Title:          Extend Tcl Process Id Control via 'pid'
Version:        $Revision: 1.8 $
Author:         Jeff Hobbs <JeffH@ActiveState.com>
Author:         Vince Darley <vincentdarley@users.sourceforge.net>
State:          Rejected
Type:           Project
Vote:           Done
Created:        11-Mar-2002
Post-History:   
Tcl-Version:    8.4

~ Abstract

This TIP proposes extended the [[pid]] command to provide more
control over native processes in Tcl.

~ Rationale

Certain process control functions have shown themselves to be portable
and of high usefulness to Tcl programmers.  Most of these already
exist in TclX, but simply requiring that extension isn't always
acceptable.  The [[pid]] command in Tcl is a command that is often
overlooked, and so simple that it lends itself easily to being
enhanced with new syntax.  This TIP proposes adding subcommands to
[[pid]] that extend the process control functionality of pure Tcl.

~ Specification

|   pid ?fileId?
|   pid terminate ?-force? ?--? pid ?pid ...?

The first line is the current definition for [[pid]], which is to
return the name of the current process id, or that attached to a
''fileId'' (as returned by [[open]] or [[socket]]).  I propose to add
only ''terminate'' initially.  This command is adapted almost directly
from TclX's signal handling, but changed to work as a subcommand of
[[pid]].  This is to satisfy one of the most common requests from
users regarding process management - killing a known process.  It also
establishes the framework of extending [[pid]] for future
modifications.  The ?-force? argument causes a forceful termination
(the usage of SIGKILL on Unix, for Windows and Mac termination is
already forceful).

~ Reference Implementation

Although TclX's current documentation denies it, the ''send'' is
already implemented for Windows (as ''kill'' under TclX) as well as
Unix.  Macintosh implementations for OS 9 and below would need to be
created, or the documentation would need to stress that these are not
available there (OS X is Unix based).  Jim Ingham notes that a variant
of ''kill'' could be created for OS 9.  These functions are really
meant to round out the process control functionality in Tcl (started
with ''exec'' and ''open|''), which are already of limited portability
to Mac OS 9 (but undeniable usefulness elsewhere).

File: ''tcl/mac/tclMacChan.c''

File: ''tcl/unix/tclUnixPipe.c''

File: ''tcl/win/tclWinPipe.c''

Function: ''Tcl_PidObjCmd''

~ Future Potential

What this also provides is a blueprint for future process management
functions like these:

|   pid id ?-user ?userIdOrName?? ?-group ?groupIdOrName?? ?-parent parentId?
|   pid wait ?-nohang bool? ?-untraced bool? ?-group bool? ?fileIdOrPid?
|   pid nice ?-level niceLevel? fileIdOrPid
|   pid list ?pattern?
|   pid id ?-session id? ?-processgroup id?
|   pid handle action signal ...
|   pid send signalType fileIdOrPid ?fileIdOrPid ...?

[[pid wait]] was in the initial tip, but it was recommended to rework
it with callback to make it much more useful to the user.  The [[pid
id]] command was intended for Unix only, operating on the current
process id, and would function similar to the [[file attributes]]
command, but Windows NT does have similar functionality.  The
''-user'' and ''-group'' options will return the name if possible,
otherwise the id. The ''-parent'' option would be read-only (like
''-longname'' for [[file attributes]]).  [[pid send]] suffers from
cross-platform portability as well.  On Windows, you can only
''raise'' signals inside of your own process.

[[pid nice]] is easy to implement, while [[pid list]] is very much
platform sensitive.  [[pid handle]] is for signal handling, another
oft-requested feature for the core, and would be based on the TclX
[[signal]] command (perhaps named ''trap'' as in Expect?).  It could
be massaged to various forms.  These aren't to be addressed in this
TIP, but are just ideas for the future.

~ Comments

|   pid kill ?-group bool? ?-signal signalType? fileIdOrPid ?fileIdOrPid ...?

This was the original form for [[pid send]], but it was noted that we
are really sending signals.  While I prefer the specificity of users
recognizing ''kill'' as a command, what this really does is send
specific signals (ANSI C specifies SIGABRT, SIGINT and SIGTERM, and
for Unix we would handle the other POSIX names too).  Thus I changed
it to the ''send'' command documented above.

[[process]] rather than [[pid]] seems a more logical name for this
command, but we are working within the constraints of the existing
commands in order to prevent command bloat.  There is still logic in
the naming, as we are dealing with process ids.

[[pid terminate]] was also recommended to have the ability to
terminate a process ''and'' all its children.  This would be useful,
but is not in the scope of the current tip.

~ Copyright

This document has been placed in the public domain.
