Hi, I've been looking at the scgi protocol and found it really easy to implement. Would there be any interest in this ? and if so, is it too late to make it into mathopd-1.6 already ?
Attached is a small proof-of-concept patch to start up the discussion. I'm not sure if majordomo likes attachments, so if it gets eaten please get it at http://www.lespinasse.org/mathopd-scgi.diff instead. The idea is this: * process_cgi was renamed into process_cgi_scgi. It builds the CGI environment as before, then calls either process_cgi or process_scgi. * process_cgi forkexecs the CGI script. The master process keeps a socketpair to talk with it. * process_scgi connects to an existing SCGI unix socket socket, and the master process keeps that socket to talk with it. The client_input pool is prefilled with the CGI environment variables converted to SCGI format. * calling writetochild directly at the end of process_scgi is not necessary for correctness, but I found out that it made a large difference (35%) in performance when the SCGI serves small (3KB) cached replies. I have a few questions about how to go further: Currently, my patch uses the following configuration item: Specials { SCGI { .scgi }} The .scgi file must exist, but it can't be the unix socket for the scgi process - otherwise, get_path_info() complains that it cannot openit. I have not found a nice workaround for this yet, so I just use a hardcoded path in process_scgi for the unix socket. Suggestions anyone ??? (I think the open is unnecessary, since the rfd will be overwritten in init_child(). Maybe a stat would be sufficient ?) The other question is about what to do when the nonblocking connect to the scgi socket returns EAGAIN. For a unix socket, this only happens if you have more backlogged connections than the scgi process's listen queue size, so I've been able to test without dropping connections as long as the number of connections supported by my test client (or by mathopd itself) stay below that number. This would not work so well if we were to generalize this for TCP connections to the SCGI process though - I think the first nonblocking connect would always return EAGAIN in this case. I'm not sure how easy would it be to extend mathopd's poll loop to also retry client connects. My third question would be about interest and release timing - I made my patch against 1.5p5 because that's what was in debian etch, but it should be easy enough to port it up if there is interest. Also, I'm not sure if there are any current plans for a mathopd 1.6 release at this point ? Thanks, -- Michel "Walken" Lespinasse A program is never fully debugged until the last user dies.
