Article on Unixlib

Alex Waugh alex at
Fri Jan 21 16:03:38 PST 2005

In message <5773d22c4d.ajw498 at>
          Alex Waugh <alex at> wrote:

> In message <81fd542c4d.Jo at>
>           John Tytgat <John.Tytgat at> wrote:
> > The moment we have UnixLib as a dynamic library this becomes less of an
> > issue as making incompatible changes in the dynamic library can go
> > together with an update of SUL.
> I think dynamic libraries is a completely separate issue, and won't
> have any effect on SUL. While minor bugfixes to UnixLib would allow you
> to replace the shared library, anything that caused a change to the ABI
> of the library would require programs to be recompiled against the new
> library, therefore you still need the old shared library present for the
> old programs to link to. Hence the situation is exactly the same as for
> statically linked programs - the SUL will have to support a range of
> UnixLib versions in either case. With a well designed process structure
> and interface, I don't think this will be too much of a burden though.

To put a bit more substance to my proposal, I think the process
structure should be something along the lines of the following.

All entries are initialied by the SUL, but some may be overwritten by
the program (particularly the environment handlers). All memory pointed
to by any entries in this structure should be allocated and freed using
the sul_malloc and sul_free routines (which will probably just be
wrappers to OS_Module, but could change in the future without breaking
compatibility). The process structure is allocated but SUL, and therefore
future SUL versions can increase the size of the structure by adding
additional entries at the end without affecting old programs. New SULs
would have to continue to support existing entries in the structure,
but I can't really envisage things like the pid needing any change. The
one thing that might is the file descriptors, but extra fields can be
added to them as their size is stored in the process structure.

One additional problem I forgot to mention that I want to solve is
closing of file descriptors, which is currently based on the pid of the
program that opened them. This is a bit simplistic, and breaks in some
situations, so I'd like to change it to using a reference count. When
the count reaches zero the underlying filehandle/socket will get closed.
The file descriptors will continue to be manipulated by the program,
SUL will only need enough knowledge to be able to duplicate them and
increment the refcount on a fork.

struct __sul_process
  void *(*sul_malloc)(size_t size); /* May be called in USR or SVC mode */
  void (*sul_free)(void *ptr);      /* May be called in USR or SVC mode */
  __pid_t pid;
  __pid_t ppid;
  __mode_t umask;
  void (*undef_handler)(void); /* Called by SUL (as the handler would normally
                                  be called, not APCS) */
  void (*addrexcp_handler)(void);
  void (*pabort_handler)(void);
  void (*dabort_handler)(void);
  void (*error_handler)(void);
  void (*escape_handler)(void);
  void (*event_handler)(void);
  void (*exit_handler)(void);
  void (*upcall_handler)(void);
  void (*callback_handler)(void);
  char **environ;
  void *(*set_wimpslot)(int); /* not sure about the exact interface to
                                 this yet */
  pid_t (*fork)(void);        /* This would only be the bits of fork that need
                                 to be in SUL, the rest would remain in the
                                 program */
  pid_t (*vfork)(void);
  __os_error *(*exec)(char *cli);
  __unixlib_fd *file_descriptors;
  int maxfd;           /* Number of entries in the file_descriptors array */
  int fdsize;          /* Size of each entry in the file_descriptors array */

/* File descriptor structure definition. One per fd */
struct __unixlib_fd
  unsigned int __magic; /* magic number for descriptor validity */
  unsigned int fs : 8; /* Filing system that file resides on */
  unsigned int device : 8; /* Device type (tty, socket etc. ) */
  unsigned int dflag : 16; /* File descriptor flags.  */
  struct __unixlib_fd_handle *devicehandle;
  int fflag; /* File status flags (attribs for opening a file) */

/* Multiple __unixlib_fd structures may point to one of these */
struct __unixlib_fd_handle {
  int refcount;
  void *handle; /* device specific field (i.e. socket, file handle) */


Alex Waugh                                           alex at

PHP, Roots, Subversion, WebJames and more from

More information about the gcc mailing list