I’m having a problem with setsockopt and SO_RCVTIMEO. I create a
SOCK_DGRAM socket, set a timeout with setsockopt, do a connect, a send,
and a recv — and my recv never times out. Any ideas?
Murf
It’s a bug. It’s been fixed internally.
-seanb
John A. Murphy <murf@perftech.com> wrote:
I’m having a problem with setsockopt and SO_RCVTIMEO. I create a
SOCK_DGRAM socket, set a timeout with setsockopt, do a connect, a send,
and a recv — and my recv never times out. Any ideas?Murf
Great! How do I get the fix?
Murf
Sean Boudreau wrote:
It’s a bug. It’s been fixed internally.
-seanb
John A. Murphy <> murf@perftech.com> > wrote:
I’m having a problem with setsockopt and SO_RCVTIMEO. I create a
SOCK_DGRAM socket, set a timeout with setsockopt, do a connect, a send,
and a recv — and my recv never times out. Any ideas?Murf
The normal way it to get it in a subsequent release.
Any special requests can be made via your sales rep.
-seanb
John A. Murphy <murf@perftech.com> wrote:
Great! How do I get the fix?
Murf
Sean Boudreau wrote:
It’s a bug. It’s been fixed internally.
-seanb
John A. Murphy <> murf@perftech.com> > wrote:
I’m having a problem with setsockopt and SO_RCVTIMEO. I create a
SOCK_DGRAM socket, set a timeout with setsockopt, do a connect, a send,
and a recv — and my recv never times out. Any ideas?Murf
Note: A workround could be to use TimerTimeout on
_NTO_TIMEOUT_SEND | _NTO_TIMEOUT_REPLY. It would be
a bit more expensive as you’d have to do it before
every recv().
-seanb
Sean Boudreau <seanb@qnx.com> wrote:
The normal way it to get it in a subsequent release.
Any special requests can be made via your sales rep.-seanb
John A. Murphy <> murf@perftech.com> > wrote:
Great! How do I get the fix?Murf
Sean Boudreau wrote:
It’s a bug. It’s been fixed internally.
-seanb
John A. Murphy <> murf@perftech.com> > wrote:
I’m having a problem with setsockopt and SO_RCVTIMEO. I create a
SOCK_DGRAM socket, set a timeout with setsockopt, do a connect, a send,
and a recv — and my recv never times out. Any ideas?Murf
Depening on the exact nature of the bug, I suppose I could also do a select with
timeout — should that work?
Murf
Sean Boudreau wrote:
Note: A workround could be to use TimerTimeout on
_NTO_TIMEOUT_SEND | _NTO_TIMEOUT_REPLY. It would be
a bit more expensive as you’d have to do it before
every recv().-seanb
Sean Boudreau <> seanb@qnx.com> > wrote:
The normal way it to get it in a subsequent release.
Any special requests can be made via your sales rep.-seanb
John A. Murphy <> murf@perftech.com> > wrote:
Great! How do I get the fix?Murf
Sean Boudreau wrote:
It’s a bug. It’s been fixed internally.
-seanb
John A. Murphy <> murf@perftech.com> > wrote:
I’m having a problem with setsockopt and SO_RCVTIMEO. I create a
SOCK_DGRAM socket, set a timeout with setsockopt, do a connect, a send,
and a recv — and my recv never times out. Any ideas?Murf
Yes, timeouts on select() work. This bug was specific to
SO_RCVTIMEO / SO_SNDTIMEO.
-seanb
John A. Murphy <murf@perftech.com> wrote:
Depening on the exact nature of the bug, I suppose I could also do a select with
timeout — should that work?Murf
Sean Boudreau wrote:
TimerTimeout does the job, except when called with NULL for event, instead of the
event defaulting to SIGEV_UNBLOCK and the recv returning ETIMEDOUT, the event
appears to default to SIGEV_INTR and recv returns EINTR.
Murf
Sean Boudreau wrote:
Note: A workround could be to use TimerTimeout on
_NTO_TIMEOUT_SEND | _NTO_TIMEOUT_REPLY. It would be
a bit more expensive as you’d have to do it before
every recv().-seanb
Sean Boudreau <> seanb@qnx.com> > wrote:
The normal way it to get it in a subsequent release.
Any special requests can be made via your sales rep.-seanb
John A. Murphy <> murf@perftech.com> > wrote:
Great! How do I get the fix?Murf
Sean Boudreau wrote:
It’s a bug. It’s been fixed internally.
-seanb
John A. Murphy <> murf@perftech.com> > wrote:
I’m having a problem with setsockopt and SO_RCVTIMEO. I create a
SOCK_DGRAM socket, set a timeout with setsockopt, do a connect, a send,
and a recv — and my recv never times out. Any ideas?Murf
Even if you don’t call TimerTimeout with NULL, but actually setup an event with
SIGEV_UNBLOCK_INIT, the recv still returns EINTR.
Murf
“John A. Murphy” wrote:
TimerTimeout does the job, except when called with NULL for event, instead of the
event defaulting to SIGEV_UNBLOCK and the recv returning ETIMEDOUT, the event
appears to default to SIGEV_INTR and recv returns EINTR.Murf
Sean Boudreau wrote:
Note: A workround could be to use TimerTimeout on
_NTO_TIMEOUT_SEND | _NTO_TIMEOUT_REPLY. It would be
a bit more expensive as you’d have to do it before
every recv().-seanb
Sean Boudreau <> seanb@qnx.com> > wrote:
The normal way it to get it in a subsequent release.
Any special requests can be made via your sales rep.-seanb
John A. Murphy <> murf@perftech.com> > wrote:
Great! How do I get the fix?Murf
Sean Boudreau wrote:
It’s a bug. It’s been fixed internally.
-seanb
John A. Murphy <> murf@perftech.com> > wrote:
I’m having a problem with setsockopt and SO_RCVTIMEO. I create a
SOCK_DGRAM socket, set a timeout with setsockopt, do a connect, a send,
and a recv — and my recv never times out. Any ideas?Murf