[Info-vax] Apache + mod_php performance

[Dan Cross]

In article <vea73n$3h7jt$1 at dont-email.me>,
Dave Froble  <davef at tsoft-inc.com> wrote:
>On 10/7/2024 2:01 PM, Dan Cross wrote:
>>> As Dave has mentioned, setting SO_SHARE on a socket would be another way
>>> to accomplish this.
>>
>> Neither of these sounds the same as descriptor passing over Unix
>> domain sockets on Unix/Linux; the auxiliary server sounds more
>> like `inetd`, in that there's some service that's listening and
>> accepting connections on some TCP/IP port, and then creating a
>> server to handle each incoming connection.
>
>I would claim that what I did is NOT passing a descriptor, or whatever, to 
>another process.  Not really sure what that means.  All I passed was the device 
>name, and let the second process assign a channel to the "existing" device (socket).

Ok.  Conceptually, this is pretty much the same thing, then, at
least as far as sockets are concerned.

>> SO_SHARE is different again; it appears that the shared socket
>> must be created before the subprocesses that use it are created.
>
>I don't know why you would say that.

I was just wrong.

>A process must exist before it can do 
>anything, but, a socket can exist in a process, and then connected to in another 
>process, regardless of when the second process is created.  For example, if a 
>bank of worker processes exist, and a task comes in, the connection socket could 
>be opened by the existing selected worker process.

The mechanism on Unix remains a little bit different, maybe, in
that there's no need to set the socket to be sharable at all;
indeed, Unix has no analogue of the `SO_SHARE` socket option on
VMS.

Vis process creation time, a scenario that could happen on Unix
is that two processes, A and B, are started; they can run for
indefinitely long, but at some point well after creation/start,
A could create a (named) Unix domain socket that is then opened
by B.  A could then create a listening socket and begin
accepting incoming connections on it, and pass those over the
Unix domain socket to B.  The two processes needn't share any
kind of parent/child relationship, nor do they have to run as
the same user, etc; as long as B has appropriate permissions to
open the socket created by A, this will all work as expected.
Indeed, this is desireable, as it provides a mechanism for
privilege separation across a process boundary.

As I gather, on VMS the analogous mechanism works since a) every
socket on the system is associated with a unique device name in
some global namespace, and b) once known, an unrelated process
can $ASSIGN that device name, subject to authorization checking
enforced by the system.  The authorization checks seem to be
either, a) a process/subprocess relationship, or b) the
assigning process has the SHARE privilege; it's not clear to me
what else could go into those checks and how that interacts with
e.g. SO_SHARE; presumably at least UIC checks or something must
be completed?

	- Dan C.