Prev: Learn about proxy sites and how to use them to open blocked sites unlimited downloads from RapidShare and megaupload and increase the speed of the Internet with new sites for free
Next: Why can't I catch a SIGBUS on my Mac (when strlen(NULL) is used)?
From: Eric Sosman on 3 Apr 2010 18:32
On 4/3/2010 6:10 PM, Peter Olcott wrote:
> [...]
> So then it is not very good for event driven operations?
> What I am looking for is some sort of callback mechanism
> that can notify me when input is available.

Most Unix things wait on "state" rather than on "events."
This is usually viewed as a Good Thing, because (examples):

- Suppose the event occurs a moment before anyone waits
for it. Lacking infinite buffer space, the kernel just
throws the event away -- and *then* somebody waits, and
waits, and waits, because the train has already left.

- Suppose the event callback takes a little longer than
expected (gets a page fault, say), and another event
arrives while the first is still being processed. What
now? A second simultaneous callback? Buffer the event
(in that infinite memory) and call again later?

That said, event-based disciplines do have their place,
mostly in real-time programming. But for "ordinary user-land
stuff," you'll probably find state friendlier than events.

--
Eric Sosman
esosman(a)ieee-dot-org.invalid
From: David Given on 3 Apr 2010 18:53
On 03/04/10 23:10, Peter Olcott wrote:
[...]
> So then it is not very good for event driven operations?
> What I am looking for is some sort of callback mechanism
> that can notify me when input is available.

Well, you can tell the kernel to send you a signal when the file
descriptor changes state --- see fcntl(F_SETFL, O_ASYNC). Normally this
is SIGIO but some Unixes (like Linux) allow you to specify any signal.

But, as I said, in my experience it's not very reliable, it's certainly
not portable, and it's not actually terribly useful given how little you
can do in a signal handler.

The normal approach for doing this sort of thing is to structure your
program like this:

{
set_up_file_descriptors();
for (;;)
{
int fd = wait_for_file_descriptor_to_change_state();
do_something_with(fd);
}
}

This gives you the event-driven model you're looking for, but in a much
more controlled manner. You can wait for a file descriptor to change
state with poll(), or if you don't have poll there's select(). If
performance is really, crucially important, there are also
platform-specific extensions like epoll() and kqueue().

--
┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ───── http://www.cowlark.com ─────
│
│ "In the beginning was the word.
│ And the word was: Content-type: text/plain" --- Unknown sage
From: Peter Olcott on 3 Apr 2010 22:25

"Eric Sosman" <esosman(a)ieee-dot-org.invalid> wrote in
message news:hp8flb$oa9$1(a)news.eternal-september.org...
> On 4/3/2010 6:10 PM, Peter Olcott wrote:
>> [...]
>> So then it is not very good for event driven operations?
>> What I am looking for is some sort of callback mechanism
>> that can notify me when input is available.
>
> Most Unix things wait on "state" rather than on
> "events."
> This is usually viewed as a Good Thing, because
> (examples):
>
> - Suppose the event occurs a moment before anyone
> waits
> for it. Lacking infinite buffer space, the kernel
> just
> throws the event away -- and *then* somebody waits,
> and
> waits, and waits, because the train has already
> left.
>
> - Suppose the event callback takes a little longer
> than
> expected (gets a page fault, say), and another event
> arrives while the first is still being processed.
> What
> now? A second simultaneous callback? Buffer the
> event
> (in that infinite memory) and call again later?
>
> That said, event-based disciplines do have their
> place,
> mostly in real-time programming. But for "ordinary
> user-land
> stuff," you'll probably find state friendlier than events.

I will be receiving up to 100 web requests per second (that
is the maximum capacity) and I want to begin processing them
as soon as they arrive hopefully without polling for them.
If I have to I will poll every 10 ms, in a thread that
sleeps for 10 ms.

>
> --
> Eric Sosman
> esosman(a)ieee-dot-org.invalid


From: Peter Olcott on 3 Apr 2010 22:42

"David Given" <dg(a)cowlark.com> wrote in message
news:hp8gt5$38u$1(a)news.eternal-september.org...
> On 03/04/10 23:10, Peter Olcott wrote:
> [...]
>> So then it is not very good for event driven operations?
>> What I am looking for is some sort of callback mechanism
>> that can notify me when input is available.
>
> Well, you can tell the kernel to send you a signal when
> the file
> descriptor changes state --- see fcntl(F_SETFL, O_ASYNC).
> Normally this
> is SIGIO but some Unixes (like Linux) allow you to specify
> any signal.
>
> But, as I said, in my experience it's not very reliable,
> it's certainly
> not portable, and it's not actually terribly useful given
> how little you
> can do in a signal handler.
>
> The normal approach for doing this sort of thing is to
> structure your
> program like this:
>
> {
> set_up_file_descriptors();
> for (;;)
> {
> int fd = wait_for_file_descriptor_to_change_state();
> do_something_with(fd);
> }
> }

That look like it would eat up too much CPU time fro my CPU
intensive process. A general approach that I know would
work would be to do the same sort of thing in a thread that
sleeps for 10 ms on every iteration. That way I get 10 ms
response and eat very little CPU. I am guessing that
pthreads can sleep for 10 ms. Perhaps I could wait for the
file size to grow?

>
> This gives you the event-driven model you're looking for,
> but in a much
> more controlled manner. You can wait for a file descriptor
> to change
> state with poll(), or if you don't have poll there's
> select(). If
> performance is really, crucially important, there are also
> platform-specific extensions like epoll() and kqueue().
>
> --
> ???? dg(a)cowlark.com ????? http://www.cowlark.com ?????
> ?
> ? "In the beginning was the word.
> ? And the word was: Content-type: text/plain" --- Unknown
> sage


From: Mark Hobley on 4 Apr 2010 02:11
In comp.unix.programmer Peter Olcott <NoSpam(a)ocr4screen.com> wrote:
> I will be receiving up to 100 web requests per second (that
> is the maximum capacity) and I want to begin processing them
> as soon as they arrive hopefully without polling for them.

That will happen. If 100 web requests come down the pipe, the receiving process
will get them.

It is only when no requests come down the pipe that the receiving process will
have to wait for a request to come in. This is no big deal.

Mark.

--
Mark Hobley
Linux User: #370818 http://markhobley.yi.org/

First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5 6 7 8 9 10 11 12
Prev: Learn about proxy sites and how to use them to open blocked sites unlimited downloads from RapidShare and megaupload and increase the speed of the Internet with new sites for free
Next: Why can't I catch a SIGBUS on my Mac (when strlen(NULL) is used)?