Re: Upcoming time boundary events

On 6/2/2025 5:01 PM, Dan Cross wrote:

In article <101l2mn$3grj7$1@dont-email.me>,
Arne Vajhøj  <arne@vajhoej.dk> wrote:

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.

 I've had Lawrence plonked for a while now.  I strongly recommend
that you do the same.  He is a troll, and does not engage in
good faith.

In this thread he first claimed that my tttt example created a new
process every time. When he was told that was wrong then he
acknowledge that. And the he noted that it would create multiple
processes is run concurrently. Which is correct.
That is good behavior.
There are other participants here that could learn
from that!

And you calling it silly was wrong.

 I noticed you didn't quote the rest of my reply.
 Like I said, I'm not convinced that one cannot write an
application that uses multiple devnames and then define logical
symbols so that it can interact with multiple clients using
transparent task-to-task communications.

So you called him silly because you think that he could be wrong
even though you don't have any specifics?
Interesting personality you have!

                                          And as I mentioned, I
don't see any structural reason that a transparent client cannot
communicate with a non-transparent server.

I am not even sure what that means.
But I am pretty sure that my code example that Lawrence was commenting
on does not do it. That was totally classic transparent all the way.
So that argument is totally irrelevant.
Arne