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

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.