Purpose: discuss what [POSIX] functionality is missing from Tcl.


[Tcl] is often promoted as a cross-operating system programming language.
POSIX is the '''Portable Operating System Interface''' (what's the X?).

The POSIX functions are supported, to various degrees, across many different
platforms.  How does Tcl's default functionality map to the POSIX description
of a portable Operating System?

In theory, one should be able to get to most aspects of POSIX from the Tcl
language without resorting to writing one's own extension.  At worst case,
there should be easy access to one or more extensions that provide access to
all of the POSIX standard functionality.

----

POSIX defines things such as:


   1. Time/Date functions
   1. File related functions 
   1. Network functions
   1. Operating System functions

----
Some missing things:

   * umask(), uid/gid management
   * signals, wait()/waitpid()
   * threads (What Tcl calls threads is more like POSIX processes. Threads would share the same interpreter state.)
   * fork() (The ability to duplicate an interpreter's state.)
   * ftruncate()
   * file locking
   * mkstemp()
   * shared memory, "mmap"-ped files, semaphores, and other IPC mechanisms
   * nice()

----
[DKF]: Commentary on the above list of missing things:
   * the umask is probably best left alone in normal apps. Seriously.
   * uid/gid ''reading'' would be really useful; ''setting'' less so (it's a restricted operation normally)
   * We deliberately don't have threads that share the state of a particular interpreter because it is a real disgusting bear of a source of bizarre problems. Some degree of sharing can be done through the [Thread] package's shared variable support.
   * Using fork() without execve() shortly after is evil, a sort of poor-man's threads that's very hard to make really portable.
   * channel truncation will definitely be in 8.5
   * file locking is another PITA that's not as portable as it looks. :^(
   * The manufacturing of temporary files might be in 8.5; there's a draft TIP for it
   * Direct access to the SYSV IPC mechanisms is unlikely; mmap()ing might happen eventually
   * niceness control comes under the heading of a "cute bell and whistle" these days

What I'd like:
   * it'd be nice to have access to ways of making [time] tell us about CPU time as well as wall time.
----
[Category Discussion]