[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Socket timeout bug (?).
- Date: 03 Sep 2002 11:21:20 +0400
- From: osv at javad.ru (Sergei Organov)
- Subject: Socket timeout bug (?).
Eric Norum <eric.norum at sasktel.net> writes:
> On Monday, September 2, 2002, at 09:49 AM, Sergei Organov wrote:
> > If I attempt to setup socket timeout using the call:
> > setsockopt(s, SOL_SOCKET, SO_RCVTIMEO, &tv, len);
> > using timeout shorter than RTEMS tick, the resulting observed behavior of
> > subsequent read(s,...) call(s) is "wait forever". I think that "wait
> > forever" should be used if and only if the timeout passed to the
> > setsockopt()
> > is exactly zero.
> > I also suspect that SO_SNDTIMEO has the same problem (not tested).
> The problem is present even in the most recent version of the FreeBSD stack.
> I guess that the FreeBSD developers never thought that someone would want to
> time out that quickly. I suggest that you report this problem to the FreeBSD
> folks. Just change 'RTEMS ticks' to 'hz' in your bug report.
Well, I don't think I can report the problem to the FreeBSD folks as in fact I
don't know and can't easily check how it actually works in FreeBSD.
I thought it's RTEMS specific as the margin is RTEMS tick length that is
obviously RTEMS specific. Anyway, I don't care much as I've encountered this
problem when I've attempted to use quick and dirty solution to achieve almost
"no wait" behavior by means of setting small timeout when the right solution
is setting O_NONBLOCK flag on the file descriptor.
After your explanations I'd rather consider this to be (undocumented?)
feature of the FreeBSD stack.