From: Dan Kegel <dank@kegel.com>
To: linux-kernel@vger.kernel.org
Subject: re: problem with rt-sigio: lost events
Date: Wed, 25 Dec 2002 22:00:14 -0800 [thread overview]
Message-ID: <3E0A9AEE.90009@kegel.com> (raw)
Felix von Leitner wrote:
> I am having trouble with sigio. I tried to integrate it in a event
> notification framework of mine that already speaks poll and epoll.
> I want sigio for backwards compatibility with 2.4 kernels.
>
> So I used the description from Dan's C10k web site and got it working.
> My test application is a trivial web server for static web pages only.
>
> My first problem is that sigio will not signal POLLOUT on freshly
> connected connections.
That's as designed (and epoll behaves that way, too, doesn't it?);
when applications start using sigio or epoll on a socket, they
have to assume it's readable/writable initially. There was a huge
argu^H^H^H^H thread about that recently with subject
"epoll (was Re: [PATCH] async poll for 2.5)"
> It doesn't change when I read the HTTP header.
> So I added a kludge that calls poll() when the application wants to
> switch from reading to writing or vice versa. That is quite ugly but it
> works.
Sounds fishy... but I'd need to see your code to know more.
> The second problem is that once I start hammering the server with
> request (as opposed to running wget manually from the command line), the
> server just stops serving requests. strace shows this pattern:
>
> sigtimedwait signals an event on fd #3 (the listening socket)
> accept is called, returns #4
> fd 4 is set non-blocking
> F_SETOWN, F_SETSIG, SETFL O_ASYNC
> sigtimedwait times out.
> sigtimedwait is called again, times out again.
>
> Why is that? Googling seemed to indicate that there could be a race
> condition here after the accept. Should I be running poll on the socket
> right away? Or just blindly call the read handler?
Yes. Blindly call the handler, and do I/O until you get an
EWOULDBLOCK. That's precisely what you're supposed to do when
you start using sigio on an fd.
> Is anyone actually successfully using sigio for anything? So far it
> does not look very reliable to me.
It works ok, once you get used to its oddities.
sys_epoll works better, but sigio isn't terrible as a fallback.
- Dan
--
Dan Kegel
Linux User #78045
http://www.kegel.com
next reply other threads:[~2002-12-26 5:41 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-12-26 6:00 Dan Kegel [this message]
-- strict thread matches above, loose matches on Subject: below --
2002-12-26 2:52 problem with rt-sigio: lost events Felix von Leitner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3E0A9AEE.90009@kegel.com \
--to=dank@kegel.com \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.