Path: ...!news.mixmin.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Lawrence D'Oliveiro <ldo@nz.invalid>
Newsgroups: comp.os.vms
Subject: Re: Apache + mod_php performance
Date: Fri, 27 Sep 2024 23:13:06 -0000 (UTC)
Organization: A noiseless patient Spider
Lines: 29
Message-ID: <vd7e62$tdq8$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>
	<vd25hj$3s2q8$1@dont-email.me> <vd3kkb$66dq$1@dont-email.me>
	<vd3r5d$74q1$1@dont-email.me> <vd5196$e44d$1@dont-email.me>
	<vd51kr$i6sg$2@dont-email.me> <vd54jp$e44c$1@dont-email.me>
	<vd55n2$ilcl$4@dont-email.me> <vd6dnk$nrif$2@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Injection-Date: Sat, 28 Sep 2024 01:13:07 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="2132f4845d2292b1a04f05d8b30f9975";
	logging-data="964424"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/Wnkw+C7MVtKmpzLguyRw9"
User-Agent: Pan/0.160 (Toresk; )
Cancel-Lock: sha1:FVALqXtDWSZaXDzeA8CUlgvwxnk=
Bytes: 2679

On Fri, 27 Sep 2024 09:59:16 -0400, Arne Vajhøj wrote:

> You setup a read attention AST, it triggers and then you know that there
> are data to be read. There is no reason to make reading async then,
> because you know it will not block.

I wouldn’t bother with ASTs at all, though I would use async QIOs with I/O 
status blocks. Here is my proposed control flow, which is very similar to 
a *nix-style poll loop:

0) Clear the event flag you are going to use in the next step.
1) Start the initial set of async QIOs on all the channels I want to 
monitor. Give them all the same event flag to set on completion (e.g. the 
usual default EFN 0). Don’t specify any completion ASTs, but do specify
I/O status blocks.
2) Wait for the specified EFN to become set.
3) Clear that EFN.
4) Go through all your I/O status blocks, and process all I/Os that have 
completed (status field ≠ 0). Queue new async I/Os for those channels (and 
any new ones) as appropriate.
5) If you still have a nonempty set of async QIOs outstanding (i.e. a 
nonempty set of channels being monitored), then go back to step 2. 
Otherwise, you are shutting down, so stop.

How does that sound?

Hmmm ... I just realized ... doesn’t QIO immediately clear the EFN you 
specify, before queueing the actual I/O request? That might blow the whole 
thing ...