Re: Upcoming time boundary events

On 6/2/2025 1:16 PM, Dan Cross wrote:

In article <101k5lf$39d9f$1@dont-email.me>,
Arne Vajhøj  <arne@vajhoej.dk> wrote:

On 6/2/2025 7:24 AM, Dan Cross wrote:

In article <mn.12937e96a0bc3b12.104627@invalid.skynet.be>,
Marc Van Dyck  <marc.gr.vandyck@invalid.skynet.be> wrote:

on 02/06/2025, Lawrence D'Oliveiro supposed :

On Sun, 1 Jun 2025 21:49:59 -0400, Arne Vajhøj wrote:

On 5/30/2025 6:41 PM, Lawrence D'Oliveiro wrote:

The irony of it, that the DEC concept requires creating a separate
server process for every client connection,

>
It doesn't.
>
Processes are re-used for task to task servers.

>
Hmm. Presumably the process is kept around for a limited time before being
shut down.
>
What about multiple concurrent connections? You can’t avoid creating extra
processes in that situation.

>
Responding generally, not specifically to Marc, but since I've
plonked the troll, I don't see his responses (I highly suggest
others do the same).
>
But this assertion in particular is silly and deserves a
rebuttal for the benefit of others.
>
I suppose the troll has never heard of event-driven programming,
or asynchronous IO, or, for that matter, threads.  Any of these
allow multiple connections to be served by a single process.

>
For TCP/IP yes.
>
For DECnet task to task??

 Yes.
 

I don't see a way to do that.

 Yes, but you're also the guy who didn't see a way to pass an
active TCP connection between processes under VMS, and who tried
to use the 4.4BSD API when I posted example code of how it's
done on Unix as an example.
 

But please enlighten us.

 Mailboxes and QIO?

????
Let us look at how it works.
1) client activate task=foobar.exe
2) DECnet note that all existing processes are in use
    and start a new process running foobar.exe
foobar.exe can do a lot of QIO on mailboxes, but that
it not gonna change that DECnet started a new process.
Arne