18 Jun
2024
18 Jun
'24
3:54 a.m.
On 2024-06-17 22:44, Paul Koning wrote:
Do you consider "accept" to be a "send" type call?
Anyway, I do consider it to be a bit broken if, after the accept, you
have some indeterminate time when before you can call send. And I would
hope you'd agree that this is a bit of a headache for anyone using the
API. Peronally, I would probably consider the accept to not have
completed until I can send data on the connection.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt(a)softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
On Jun 16, 2024, at 7:03 PM, Johnny Billquist
<bqt(a)softjar.se> wrote:
On 2024-06-16 22:40, Paul Koning wrote:
Or you could not return from the accept until the state change to run?
Possible, but currently none of the "send" type API calls in PyDECnet do any
waiting. They either accept or reject the request, and if accepted they set it in motion,
but none wait for it to finish (for some definition of "finish"). On Jun
16, 2024, at 4:36 PM, Keith Halewood <Keith.Halewood(a)pitbulluk.org> wrote:
I approached this from VMS task communication. On a VMS host, I can write a command
procedure and create an object definition, say XXX, to output some data to SYS$NET then
refer to it remotely with something like
TYPE node::"=XXX"
This works quite well without the need for the caller to send something first. I had
hoped this would be the case with PyDECnet too.
Is there any way of making a conn.accept() wait for the state change?
I could
change the code to implement queueing until the state changes to RUN.