in reply to fork() emulation hack for OpenVMS

Generally on VMS the way things like this are done is via nonblocking pending locks with callback ASTs on lock aquisition, or monitoring mailboxes for notifications from spawned subprocesses.

VMS fully supports tying the input and output handles to a spawned subprocess simultaneously, though I don't think anyone's gotten around to adding it to VMS perl (The infamous open FOO, "| process |" that doesn't work on Unix).

Probably the right thing to do is to spawn off subprocesses with normal magic open capturing the output of the child process and monitor the return filehandle. Or you could use a threaded perl, I suppose, if you don't want to do that.

Replies are listed 'Best First'.
Re: Re: fork() emulation hack for OpenVMS
by agarsha (Acolyte) on Mar 09, 2003 at 19:09 UTC
    Since I am already going to have to have the dreaded:

    elsif ( $os =~ /OpenVMS/ ) {# Do something VMS style}

    I am open to doing things completely vms-style for VMS; I suppose that since Perl is written on Unix and ported to VMS, that none of the mailbox api, nor nonblocking_lock/callback stuff is exposed.

    I will have to sniff around for pre-compiled Modules/libs, if you happen to have any mods in-mind, let me know. I will hit google for them with or without response. If no pre-compiled available, I'll have to look into Compaq C compiler acquistion (big-$$$).

    Do you happen to know if mailbox/nonblocking_lock->callback stuff is available via DCL? If so, will see if one of my more VMS savvy co-workers can help me put some stuff together for call-out/cheap-exposure-to-perl.

    Comments: Don't trust threaded perl yet + have a bunch of legacy multi-proc code; Don't think I can do non-blocking select on pipes with VMS, so the magic open is a no-go.

    Thanks for your kind/timely response. --adam

[reply]
Re: Re: fork() emulation hack for OpenVMS
by Anonymous Monk on Mar 09, 2003 at 19:09 UTC
    How does VMS handle the buffering issues?

    I mean, how do you handle the situation where a child process is waiting on input while you are waiting on output?

[reply]

      Shrug. Haven't written any of the code yet for VMS. Probing right now. "select" DOES work in the normal fashion for sockets... just not pipes/filehandles (according to documentation-that-I-can't-find-right-now).

      Looks like "alarm" is supported :)

      --adam

[reply]
      Generally you don't do that. The paradigm is different.

      Since all of VMS' I/O is potentially asynchronous (and the cluster locking mechanism is considered I/O, of a sort) and you can attach a custom callback and one piece of custom data to each I/O request, as well as wait for one of a set of general "event done" bits to be set. What's generally done is either:

      • Your callback routine initiates the next stage of the task. This is common in bulk copy code such as the VMS backup program--each completed read request has an AST that initiates a write request for the data read, and each completed write request initiates a read for the next chunk. Get a few of these in flight simultaneously and it's easy to get a lot of throughput.
      • Your callback inserts a chunk of data into an AST/interrupt/threadsafe queue (and the system has these) and pings the "event done" bit, at which time the mainline code wakes up, drains the queue, then goes back to sleep waiting on the bit again. This is something like select, only sucks much less.
      The whole "waiting for input & output & stalling" case generally doesn't arise since there's no sync I/O going on. Unfortunately it is a bit more complex than plain sync I/O.
[reply]

In Section Seekers of Perl Wisdom