[Info-vax] Apache + mod_php performance

Dave Froble davef at tsoft-inc.com
Fri Oct 11 12:31:03 EDT 2024


On 10/11/2024 9:30 AM, Dan Cross wrote:
> 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.
>

The share flag is for the device.

-- 
David Froble                       Tel: 724-529-0450
Dave Froble Enterprises, Inc.      E-Mail: davef at tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA  15486


More information about the Info-vax mailing list