Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: =?UTF-8?Q?Arne_Vajh=C3=B8j?= <arne@vajhoej.dk>
Newsgroups: comp.os.vms
Subject: Re: Apache + mod_php performance
Date: Sun, 29 Sep 2024 21:42:48 -0400
Organization: A noiseless patient Spider
Lines: 43
Message-ID: <vdcvmo$1tq3s$3@dont-email.me>
References: <vcv0bl$39mnj$1@dont-email.me> <vcvmu1$3cnv1$2@dont-email.me>
 <vd10re$nmp$1@reader1.panix.com> <vd1bdp$3npm3$1@dont-email.me>
 <vd1lgd$dbq$1@reader1.panix.com> <vd1u8j$3qqpg$1@dont-email.me>
 <vd7hbi$tgu3$2@dont-email.me> <66f8183e$0$715$14726298@news.sunsite.dk>
 <66f8a44c$0$716$14726298@news.sunsite.dk> <vda9tl$1facd$1@dont-email.me>
 <vdaala$1es94$1@dont-email.me> <vdab8a$1facd$7@dont-email.me>
 <vdbp7k$1pg2p$1@dont-email.me> <vdcm06$1tmdr$2@dont-email.me>
 <vdcn50$1tq3t$1@dont-email.me> <vdcom4$1tmdr$13@dont-email.me>
 <vdcpri$1tq3s$1@dont-email.me> <vdcufi$1unhf$2@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Mon, 30 Sep 2024 03:42:49 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="dd4388f3a98a50c6a6a8453b40be4e07";
	logging-data="2025596"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19U/QAQQfTXTVRS+1h91E5AffV3B0q/w2I="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:93M+6Ai/rtt95QuNxmLL87YX59k=
In-Reply-To: <vdcufi$1unhf$2@dont-email.me>
Content-Language: en-US
Bytes: 3422

On 9/29/2024 9:21 PM, Lawrence D'Oliveiro wrote:
> On Sun, 29 Sep 2024 20:02:59 -0400, Arne Vajhøj wrote:
>> On 9/29/2024 7:43 PM, Lawrence D'Oliveiro wrote:
>>> On Sun, 29 Sep 2024 19:16:48 -0400, Arne Vajhøj wrote:
>>>> On 9/29/2024 6:57 PM, Lawrence D'Oliveiro wrote:
>>>>> On Sun, 29 Sep 2024 10:46:12 -0400, Arne Vajhøj wrote:
>>>>>> And I don't understand the "put all the client context into shared
>>>>>> memory" either. Are you saying that if socket descriptors are put in
>>>>>> shared memory then any process that map that memory can use those
>>>>>> sockets????
>>>>>
>>>>> No, but the shared-memory context can contain an index into a table
>>>>> of socket descriptors in private per-process memory. If the process
>>>>> trying to server a client context does not actually have a socket
>>>>> descriptor in the slot for that context, it can ask for one.
>>>>
>>>> I still can't follow the idea.
>>>>
>>>> Client X has a connection to server worker A. That means that A has
>>>> index 77 in shared memory that points to the socket descriptor for the
>>>> connection from X.
>>>>
>>>> Worker B wants to serve X as well and it get index 77 from shared
>>>> memory. And then it does what?
>>>
>>> Looks up its entry in its process-private copy of the array that
>>> contains the socket descriptors, to see if it has its own valid fd for
>>> that socket.
>>
>> Yes. And if it does not then what?
> 
> Then it asks another process for a copy of that socket descriptor. Perhaps
> there is one overall connection-management process that accepts all new
> connections; if not, another worker that has that socket can pass it
> along.

It should not be a problem of copying a socket descriptor from one
process to another process - I believe it is just an int.

But will it work in the other process????

Arne