httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From (Robert S. Thau)
Subject Re: Threading, 2.0 and 1.2
Date Thu, 11 Jul 1996 21:57:43 GMT
Jim, my current threaded prototype is running off a threads package
which I wrote with the deliberate goal of making it as portable as
possible, by keeping the amount of machine-specific code to a bare
minimum (thread startup and almost nothing else).  Ben's port to SCO,
for instance, involved adding SCO5 to this #ifdef:

  typedef struct { jmp_buf b; } MACHINE_STATE;

  #if defined(SOLARIS2) || defined(SYSV) || defined(SCO5)
  #define SAVE_MACHINE_STATE(buf) setjmp((buf)->b)
  #define RESTORE_MACHINE_STATE(buf) longjmp((buf)->b, 1)
  #define SAVE_MACHINE_STATE(buf) _setjmp((buf)->b)
  #define RESTORE_MACHINE_STATE(buf) _longjmp((buf)->b, 1)

... and writing this (which did require him to figure out at least
a bit about how longjmp() works on SCO):

  static void set_machine_state (MACHINE_STATE *state, void (*init_func)(),
  			         char *stack_lo_addr, char *stack_hi_addr)
      /* Yet another platform where sigfoostack behaves strangely */
      SAVE_MACHINE_STATE (state);      
      (state->b)[5] = (int)init_func;
      (state->b)[4] = (int)stack_hi_addr;

... in which the comment alludes to some generic routines which manage
to work on many systems (most supporting sigstack() or sigaltstack())
without any overtly processor-specific code at all, but which
unfortunately don't work on SCO5.  (He subsequently wrote a bit more
code for dbx debugger support, since he doesn't have gdb on SCO).  

I don't *think* a port to A/UX would be any worse, but there's really
no way to find out short of trying it.

(NB, the best thing to do if you have a spare afternoon for this is to
start off with the threads package's own test routines; if those work,
the threads package is probably OK, and if not, you don't have to
worry about where in the server package as a whole things are going


View raw message