Jeff HobbsVince Darley$Revision: 1.9 $

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

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.

ICAgcGlkID9maWxlSWQ/ICAgcGlkIHRlcm1pbmF0ZSA/LWZvcmNlPyA/LS0/IHBpZCA/cGlkIC4uLj8= 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).

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

What this also provides is a blueprint for future process management functions like these: ICAgcGlkIGlkID8tdXNlciA/dXNlcklkT3JOYW1lPz8gPy1ncm91cCA/Z3JvdXBJZE9yTmFtZT8/ID8tcGFyZW50IHBhcmVudElkPw==ICAgcGlkIHdhaXQgPy1ub2hhbmcgYm9vbD8gPy11bnRyYWNlZCBib29sPyA/LWdyb3VwIGJvb2w/ID9maWxlSWRPclBpZD8=ICAgcGlkIG5pY2UgPy1sZXZlbCBuaWNlTGV2ZWw/IGZpbGVJZE9yUGlkICAgcGlkIGxpc3QgP3BhdHRlcm4/ICAgcGlkIGlkID8tc2Vzc2lvbiBpZD8gPy1wcm9jZXNzZ3JvdXAgaWQ/ICAgcGlkIGhhbmRsZSBhY3Rpb24gc2lnbmFsIC4uLg==ICAgcGlkIHNlbmQgc2lnbmFsVHlwZSBmaWxlSWRPclBpZCA/ZmlsZUlkT3JQaWQgLi4uPw== [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.

ICAgcGlkIGtpbGwgPy1ncm91cCBib29sPyA/LXNpZ25hbCBzaWduYWxUeXBlPyBmaWxlSWRPclBpZCA/ZmlsZUlkT3JQaWQgLi4uPw== 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.

This document has been placed in the public domain.