If an event is triggered at about the same time as a timeout expires,
the port_getn() libc interface can return with
retcode: -1
errno: ETIME
number of events: updated to > 0
The -1/ETIME must be ignored and the event(s) processed, as the kernel
will not report it again until after a subsequent call to port_associate().
I've seen it on 2009.06 and S10U7.
The man page has two descriptions for ETIME:
The port_get() and port_getn() functions will fail if:
...
ETIME The time interval expired before the expected
number of events have been posted to the port.
...
The port_getn() function will fail if:
...
ETIME The time interval expired before the expected
number of events have been posted to the port
(original value in nget), or nget is updated with
the number of returned port_event_t structures in
list[].
The second description of ETIME is perhaps unclear (is it "before A or B
occurs" or "before A occurs; otherwise"); regardless, neither
description mentions this behavior.
I couldn't reproduce this behavior with port_get().
libevent handles/works around this behavior as follows (see the "errno
== ETIME" path):
if ((res = port_getn(epdp->ed_port, pevtlist, EVENTS_PER_GETN,
&nevents, &ts)) == -1) {
if (errno == EINTR) {
evsignal_process();
return (0);
} else if (errno == ETIME) {
if (nevents == 0)
return (0);
} else {
perror("port_getn");
return (-1);
}
This newbie finds the special ETIME check in port_getn() at
http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/lib/libc/port/gen/event_port.c
surprising, but then of course I would since ETIME is the heart of the
problem.
Can anyone advise on how an app can avoid pitfalls in this area
regardless of *Solaris level?
I will open a bug at bugs.opensolaris.org to fix the code or the doc,
unless for some reason shared here it isn't needed or there is a better
way to resolve the issue.
Thanks!
_______________________________________________
networking-discuss mailing list
networking-discuss@opensolaris.org
