Liste des Groupes | Revenir à co vms |
On Thu, 10 Oct 2024 23:01:13 -0400I posted the sample code.
Dave Froble <davef@tsoft-inc.com> wrote:
>On 10/7/2024 4:07 AM, Michael S wrote:>On Mon, 7 Oct 2024 00:35:36 -0400>
Dave Froble <davef@tsoft-inc.com> wrote:
>On 10/6/2024 11:12 AM, Michael S wrote:>On Fri, 4 Oct 2024 17:43:02 -0000 (UTC)>
cross@spitfire.i.gajendra.net (Dan Cross) wrote:
>In article <vdp8kn$a67s$1@dont-email.me>,>
Dave Froble <davef@tsoft-inc.com> wrote:On 10/3/2024 7:00 PM, Chris Townley wrote:>[snip]>
I don't remember George, but we have certainly woken up Dave!
;)
>
and I am sure the troll is happy...
I'm not sure whether I've been insulted?
I suspect the "troll" reference is to Lawrence. Sadly, Arne can
not help himself when it comes to resisting arguing with that
clown.
>
- Dan C.
>
Troll or not, but the question about ability to pass open TCP
socket to child process (or, may be, to unrelated process) under
VMS is a good question.
As a lurker, I am waiting for the expert answer with interest.
>
Well, some of the issue is in the text of the question. What does
one mean be "pass socket"?
>
When creating a socket, one can specify it to be shared. What I
was doing was passing the information to a worker process, then
letting the worker process open the existing socket.
>
So, would that be considered "passing an open socket"?
>
Yes, it would be.
>
On Windows one has to go through similar 3-stage procedure:
- [in parent process] acquire magic record from the open socket by
means of WSADuplicateSocket()
- pass the record to child by any of available IPC mechanisms
- [in child process] use magic record to re-open socket with
WSASocket()
>
I never had a need of for it in practice. Looking at docs it seems
that the procedure above has at least one inconvenient aspect - the
target process has to exist at the moment of WSADuplicateSocket()
call. Still, I suppose that it's better than nothing.
>I can post some of the development code is anyone is interested. I>
was working on the inter-process communications when I dropped the
project. I believe I did open the shared socket in the worker
process.
>
May be, others are interested in the code.
For me, I'd rather read textual description of the procedure and war
story of making it work.
>
Actually, simple.
>
1) Create the socket in listener process
2) Pass device name to worker process
3) Assign a channel to the device in worker process
4) deassign the channel in listener process (if desired)
>
There are few pieces in your simple explanation that I don't understand:
- How does listener get a device name?Note that we're discussing BG devices.
- What is "channel"? Is it the same as 'socket'?Channel is VMS channel
- How one "assigns" channel to device? I would guess that device has toIf one has a device name, then one can assign a channel to that device.
be open before that?
- Is device name of the socket system-global?Yes, I think so.
If yes, does it mean that any process in the system that happens toIf shared access is specified, then yes.
know a name can open a device and assign it to channel?
Les messages affichés proviennent d'usenet.