TODO

* Implement controlling signal disposition
  (see devdoc/trap-cmds.txt).

* Implement [block] (and [unblock]?).
  They should possibly accept an open list of
  arguments which is to be interpreted as signals.

  Note that the behaviour of sigprocmask() should
  be closely modelled, i.e. there should be a way
  to replace the blocked signals with the specified
  list, add the specified signals to the list of
  blocked signals, remove them and query the
  current list of blocked signals.

  Possibly subcommands would do, like this:
  block replace SIGFOO SIGBAR...
  block add SIGFOO SIGBAR...
  block remove SIGFOO SIGBAR...
  block replace {} ;# unblock all
  block remove all ;# unblock all

  Possibly "set" is more sensible than "replace",
  like this:
  block set SIGFOO SIGBAR...
  block set {} ;# unblock all

  [unblock] could be used as a more human-readable
  alternative to certain [block] variants, like this:
  unblock SIGFOO SIGBAR... ;# same as [block remove ...]
  unblock all ;# same as [block replace {}]

* Investigate possibility to improve implementation
  of signal tables.
  Factoring out their handling to a common
  data structure looks interesting.

* Try to simplify the implementation of
  InfoCmd_Signum and InfoCmd_Name.

* Looks there's no more code that calls
  GetSignumByName and GetNameBySignum
  with interp != NULL.
  If so, their implementation should possibly
  be updated.

* Consider removal of GetSignumByName()
  and GetNameBySignum() from unix/sigtables.c
  as the code implementing signal objects
  now uses FindSignalBy*() functions.

* Provide for listing of POSIX real-time signals
  in the signals[] table.

  The problem is that a) the number of such signals
  is not fixed; b) their min and max numbers are
  not fixed.
  This imples we possibly have to make up a dynamic
  table of signals, or may be move directly to
  storing the "signal objects" instead of just pairs
  of signal name and number.

  Also it's not quite clear is it possible for
  SIGRTMIN to change at runtime or we're guaranteed
  that it stays the same over the lifetime of the
  process.

* Hash table lookup functions should mimic the behaviour
  of Tcl_GetIndexFromObj() and return a proper error
  message which includes all the allowed elements from
  the respective tables.

  NOTE: it might turn out that the generation of such
  a message should be left out for some other code,
  and unix/sigtables.c is just to provide
  GetListOfNames and GetListOfSignums.

* Implement changing signal disposition to
  SIG_DFL and SIG_IGN.

* Think about a robust way to keep signal dispositions
  and the table of syncpoints in sync.

* Think about saving the "subverted" signal handler
  (returned by sigaction() with non-empty last arg)
  and providing for a) calling of this handler;
  b) restoring it.
  This could be useful for interoperating with
  other signal-handling extensions or even with the core.

* GDB lists a whole lot of signals (via its "info signals"
  command) which signal(7) doesn't mention
  (on Debian Lenny).
  It worth studying whether inclusion of these signals
  is desired or not.

* Looks like our package fails to load after the
  Thread package is loaded while current dir
  appears to be unchanged.

  Indeed, it seems like a subtle problem with Tcl's [load]
  command, as its idea about the current directory
  might be different from that of the system, because after,
  say, the Thread package is loaded,
  [file exists libposixsignal0.1.so] returns 1
  but [load] on a non-qualified name fails, *and* it works
  for the full file name.

* Do we really need signal vector for initialization?
  Currently only creation of the table of event handlers
  could benefit from it, and the elements of the
  table of syncpoints are initially initialized to NULL.
  On the other hand, this might prove as being a more
  universal approach, especially if the table of syncpoints
  will change its format.