Re: Upcoming time boundary events

On 6/2/2025 4:23 PM, Dan Cross wrote:

In article <683de86d$0$684$14726298@news.sunsite.dk>,
Arne Vajhøj  <arne@vajhoej.dk> wrote:

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.

 Two cases: transparent task-to-task, and non-transparent.
You just said "DECnet task to task".
 Earlier in the thread, Marc mentioned transparent task-to-task,
but you didn't say that.  Non-transparent task-to-task
communications over DECnet do not require a new process; they
can make use of all of the techniques I mentioned earlier.

I did not say transparent but the code I posted and Lawrence
commented on was transparent task to task.
Which means that Lawrences comment was actually correct.
And you calling it silly was wrong.
Arne