httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ben Laurie <>
Subject Re: Threading, 2.0 and 1.2
Date Thu, 11 Jul 1996 21:54:40 GMT
Robert S. Thau wrote:
> 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)
>   #else
>   #define SAVE_MACHINE_STATE(buf) _setjmp((buf)->b)
>   #define RESTORE_MACHINE_STATE(buf) _longjmp((buf)->b, 1)
>   #endif
> ... 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 */

To be fair to SCO, the sigfoostack stuff doesn't work not because it behaves
strangely but because it behaves ultra-correctly. That is, it realises that you
are trying to pull the wool over its eyes and refuses to play ball. To mix a

>       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
> south).

That has certainly been my experience. The only time I've had to debug the
threading in Apache itself turned out to be that blasted Netscape keepalive



> rst

Ben Laurie                  Phone: +44 (181) 994 6435
Freelance Consultant and    Fax:   +44 (181) 994 6472
Technical Director          Email:
A.L. Digital Ltd,           URL:
London, England.

View raw message