Re: Apache + mod_php performance

In article <vea73n$3h7jt$1@dont-email.me>,
Dave Froble  <davef@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.
>