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?). FW: I think it's just that there's a tradition of naming OSes "*ix"
Cla The name is of course derived from UNIX.
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:
- Time/Date functions
- File related functions
- Network functions
- 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.
- The Thread package will ship with 8.6; it is necessary to utilize modern multicore hardware correctly.
- 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. :^( LV Note however the only thing to which I was referring was a simple interface to the POSIX file locking - not a universal solution to a nearly unsolvablel problem.
- usually prefer to delegate this to a specialist data handling library; SQLite gets it right.
- 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.
CL agrees with Donal, sometimes enthusiastically, while continuing to pine for Thread functionality to share procs (or equivalent).
Strick: Are any of these Posix calls missing from TclX? (And thanks for not getting us messed up in Threads!)
FW: Out of curiosity, how many of these does Java fulfil?
DKF: I don't remember for sure, but they've definitely got an mmap() equivalent.
Sarnold 11/01/2005 Wouldn't you like to have some socket options like with setsockopt() function?
DKF: They'd be nice as a small TIP, but they're not so much a part of any posix support as they'd be portable to other platforms (*ahem*Windows*ahem*) too.
RFox: Which of the POSIX Standards are we talking about? There's
- .1 which are core OS Services,
- .1b which are real-time services
- I, that's where shared memory and (IIRC) mmap lives
- .1c is where pthreads lives.
- .2 we're probably not interested in. As that's the command shell and common utilities are defined.