errno issues.

[Robert S. Thau]

Godmar Back writes:
 > If somebody writes a native library that makes use of calls that
 > set errno, they'll have to go through the syscall interface anyway.
 > The way this is currently done is by using convenience macros defined
 > in jsyscall.h, which native libs must include if they want to use read(),
 > write(), etc.  Note that there is no other way:  we assume we link
 > against a C library that is oblivious to our internal threading system,
 > hence we must protect calls to that library and errno ourselves.

FWIW, the Posix threads spec (pthreads) requires the threaded version
of <errno.h> to define errno as a preprocessor macro expanding to a
pointer to thread-specific data in some unspecified manner.  If a
userland implementation has a global variable pointing to some control
block for the currently running thread, then

  #define errno (__Pthr_current->errno)

or the moral equivalent is, I believe, OK, though most implementations
do something like

  extern int* __errno_location();
  #define errno (*__errno_location())

which imposes rather more overhead.  However, if you have kernel
threads on a multiprocessor system, so that multiple threads can be
literally running simultaneously, then the former approach requires
real voodoo to work effectively --- you have to store the
__Pthr_current (or whatever) variable in something like a register
which can have different values in different simultaneously running
threads, and that requires cooperation from the compiler.  (Which gcc
can provide if you've got a register to spare, but x86 processors tend
to get rather cramped).

Food for thought...

rst