Deutsch English Français Italiano |
<veb9ab$ar2$1@reader1.panix.com> View for Bookmarking (what is this?) Look up another Usenet article |
Path: ...!weretis.net!feeder9.news.weretis.net!panix!.POSTED.spitfire.i.gajendra.net!not-for-mail From: cross@spitfire.i.gajendra.net (Dan Cross) Newsgroups: comp.os.vms Subject: Re: Apache + mod_php performance Date: Fri, 11 Oct 2024 13:30:51 -0000 (UTC) Organization: PANIX Public Access Internet and UNIX, NYC Message-ID: <veb9ab$ar2$1@reader1.panix.com> References: <vcv0bl$39mnj$1@dont-email.me> <ve13ck$1pl4l$1@dont-email.me> <ve17mc$osk$1@reader1.panix.com> <vea73n$3h7jt$1@dont-email.me> Injection-Date: Fri, 11 Oct 2024 13:30:51 -0000 (UTC) Injection-Info: reader1.panix.com; posting-host="spitfire.i.gajendra.net:166.84.136.80"; logging-data="11106"; mail-complaints-to="abuse@panix.com" X-Newsreader: trn 4.0-test77 (Sep 1, 2010) Originator: cross@spitfire.i.gajendra.net (Dan Cross) Bytes: 3862 Lines: 62 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.