Operating System - OpenVMS
cancel
Showing results for 
Search instead for 
Did you mean: 

timeout for sys$waitfr

 
SOLVED
Go to solution
Alex Chupahin
Super Advisor

Re: timeout for sys$waitfr

Yes, I see I make some fusion with this sys$getjpi... sorry. This is only an example that set up the event flag....
No reason to treat it as final conclusion.
I'm in search to find a way with signaling technique. The software I porting use poll for it (such a strange idea I think). I wish to remove poll for OpenVMS and use event flag. But I need to wait events for fixed time period.
Ian Miller.
Honored Contributor

Re: timeout for sys$waitfr

If the intent is to pause for a specified delay then use lib$wait
____________________
Purely Personal Opinion
Robert Gezelter
Honored Contributor

Re: timeout for sys$waitfr

Alex,

The only words that come to mind when "polling" is mentioned as a technique are not usable in a gentlemen's [gentleperson's ?] forum. {To be precise, they are associated with various ailments of the mammalian digestive tract; certainly not pretty.)

Inter-process communications translates the problem into a different realm. There are many side issues, beyond the normal case. Often, I have used DECnet logical links to connect processes. The advantage of this is two fold: the ability to use ASTs as a event notification vehicle, and almost more importantly, OpenVMS' automatic disconnection of a logical link when a process exits for any reason. The disadvantage is that one side of this connection must hold SYSNAM to accept multiple incoming connections from different clients, as is often the case.

Mailboxes can be used to accept streams of event notifications. The problem is that there is generally no notification if the partner process disappears. Fewer privileges are needed in this case.

Event flags, as in cluster common event flags, can also be used. These are event flag groups that are shared among a group of different processes within a common group. I refer you to the OpenVMS Programming Concepts manual for a more detailed description.

I would be very careful about using a single event flag for both TIMER and another operation, as has been mentioned. There are race conditions that can occur, both in the handling of the event flag and in the processing of the other system call. Some of these are subtle.

For example, the following sequence:

Declare Timer
A: Call GetJPI
B: Check if Timer expired

The Timer can expire before the GETJPI has even been queued. If there is a higher priority process on the system. It may not be common, but it can happen. Similarly, even though the Timer fires first, between the timer being fired and the AST being processed, it is possible for the other event to be complete. Extreme caution is recommended to avoid creating a rare and difficult to reproduce failure mode.

- Bob Gezelter, http://www.rlgsc.com

abrsvc
Respected Contributor

Re: timeout for sys$waitfr

Perhaps the bottom line here is that there are many potential implementaion options which each have their strengths and weaknesses. Without a clear understanding of the particulars of hte problem being solved, we can only provide generic methods. This can be either a simple implementation or complex. I tend to prefer the simple solutions as they are less likely to bite me later...

I might suggest that you consult with someone with more VMS experience about the details of the problem. In the interest of full disclosure, many of us here provide such consultation. Your problems may require more detail than can easily be discussed in this forum.

Dan
Hoff
Honored Contributor

Re: timeout for sys$waitfr

The Programming Concepts manual has details on various of the options.

Consider threads.

Or sys$qio or other service with a completion AST; that's event-driven, and may or may not be feasible.

Or a repeating series of ASTs using sys$setimr.

Or issue a sys$schdwk, and a loop. Do something. $hiber. Loop to something. Repeat.

It's possible that the code here may work more or less directly, depending on what's going on within its logic.

What's going on depends on the details of the code, and how far the port can or should diverge from the code.

There are limits around the select() and poll() calls in VMS, though those may be an option.

Event flags and polling are comparatively evil solutions, though the former tends to be more subtle about it.

As fun as it is to rant about the messes that event flags cause, what is the open source package involved, and cam we get a source code pointer to the problematic code? What is the target OpenVMS version and architecture(s) for the port? The C library is a consideration here; the older you aim for with this port, the fewer C calls available.
Craig A Berry
Honored Contributor

Re: timeout for sys$waitfr

If the thing you're waiting on is a file or device, and if the thing you're waiting to have happen is some sort of I/O on that file or device, consider read and/or write attention ASTs. I think details would be in the I/O User's Guide.
Highlighted
Alex Chupahin
Super Advisor

Re: timeout for sys$waitfr

Thanks for help very much, its makes all for me.

Interesting, widely saying, what about good select emulation idea via system service routines?

So, there is a socket array fd_read for read,
there is a
select(1,*fd_read, NULL, NULL, timeval)
for this socket.

What is a good idea to get same functionality with event flags?
Hoff
Honored Contributor

Re: timeout for sys$waitfr

You'll be using system services and specifically $qio or $qiow calls here, with completion event flags or with completion AST calls, depending on your goals.

The RTLs provide wrappers around these services.

The TCP/IP $qio interface is documented in the TCP/IP Services documentation shelf, at hp.com/go/vms/doc

There are examples in the TCPIP$EXAMPLES: directory.