httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dean Gaudet <dgau...@arctic.org>
Subject Re: OpenVMS patches, porting issues
Date Thu, 08 Jul 1999 15:38:02 GMT


On Thu, 8 Jul 1999, Dave Jones wrote:

> I posted a set of patches for Apache 1.3.6 that allow it to run under
> OpenVMS at http://www.er6.eng.ohio-state.edu/~jonesd/apache/ that reflect
> the current state of porting efforts.  There are roughly 15 differences
> files and a zip file containing 2 dozen new files (mostly build scripts) for 
> ./src/os/openvms/.
> 
> The biggest headaches in the port are, naturally, forking and signals -
> they just don't map well to VMS.  I knew forks were going to require
> workarounds, but was blindsided by subtle bugs caused by the assumptions
> Apache makes about signal handling.  In VMS, C I/O functions like
> accept() and read() are not kernel calls and don't abort when a signal
> is delivered.  What happens therefore are things like:

You'll find apache-2.0/mpm to be much easier to work with then I think. 
It doesn't use signals... 

>    - The timeout signal handler for keep-alive waits gets an EBUSY
>      error when it tries to close the connection to the client, leaving
>      the connection open and the client hanging.  The client tries to send
>      a request on the open connection but the server thinks the connection
>      has been closed (apache doesn't check the close status) and thus doesn't 
>      read it.
> 
>    - The USR1 signal handler that sets the deferred_die flag assumes the
>      accept() call the idle child is blocking on will abort with an EINTR
>      error, see deferred_die true, and exit.  In VMS, returning from the
>      signal handler resumes the accept() call and the process continues
>      waiting, clearing deferred_die when a new connection is received.
> 
> I've put in kludges to work around these signal-related issues.

Yeah sounds painful. 

Dean



Mime
View raw message