-
Stopping a kqueue
Hi all,
I tried asking this in comp.lang.c and comp.lang.c++ but in neither
place had anyone ever heard of kqueue or kevent so I'm hoping I might
have more luck here.
I've got some code which monitors a file by way of the kqueue/kevent
mechanism but I'm having trouble getting it to shut down cleanly.
My thread dedicated to the kqueue is basically a while-loop which
blocks on the kevent() call until an event is posted, at which point it
rattles through and does what it's supposed to. So far so good.
while(watcherRunning==true){
n = kevent(kq, NULL, 0, out_list, 255, NULL);
//got an event, do something with it.
}
The problem comes when I want to stop monitoring the file. As far as I
can see, the only way to get it to stop is to set "watcherRunning" to
false (from within a separate thread) and then actually make a change
to the file in order to trigger a kevent and unblock the thread!
Surely there must be a nicer way to do it?
Is there any way to trigger/post a kevent programmatically?
I don't really want to set a timeout on the event blocking as that
isn't really practical and it also turns it into a poll thereby
defeating the purpose of using a kqueue in the first place!
I'm tearing my hair out, can anyone help please?
Thanks a million for any help.
W
-
Re: Stopping a kqueue
Bill <anon@myspace.com> wrote:[color=blue]
>
> while(watcherRunning==true){
> n = kevent(kq, NULL, 0, out_list, 255, NULL);
> //got an event, do something with it.
> }
>
> The problem comes when I want to stop monitoring the file. As far as I
> can see, the only way to get it to stop is to set "watcherRunning" to
> false (from within a separate thread) and then actually make a change
> to the file in order to trigger a kevent and unblock the thread!
> Surely there must be a nicer way to do it?[/color]
Well, if you take as an example /usr/src/usr.bin/tail/forward.c which
uses kevent to follow file modifications, they use a timeout to break
out of the sort of loop you are writing:
for(;;) { ..... <read the file, then wait for modification>
n = kevent(kq, NULL, 0, ev, 1, Fflag ? &ts : NULL);
if (n < 0)
err(1, "kevent");
if (n == 0) {
/* timeout */
break;
.....
Otherwise the kevent remains blocked in kernel until the file is
modified.
--
Michel TALON
-
Re: Stopping a kqueue
In article <2007012600111216807-anon@myspacecom> Bill <anon@myspace.com>
writes:[color=blue]
>
>My thread dedicated to the kqueue is basically a while-loop which
>blocks on the kevent() call until an event is posted, at which point it
>rattles through and does what it's supposed to. So far so good.
>
>while(watcherRunning==true){
> n = kevent(kq, NULL, 0, out_list, 255, NULL);
> //got an event, do something with it.
>}
>
>The problem comes when I want to stop monitoring the file. As far as I
>can see, the only way to get it to stop is to set "watcherRunning" to
>false (from within a separate thread) and then actually make a change
>to the file in order to trigger a kevent and unblock the thread!
>Surely there must be a nicer way to do it?[/color]
Well, I've never actually used this stuff, but from reading the man
page, I believe you could get the thread out of the loop by sending it a
signal (probably using pthread_kill()) after setting watcherRunning to
false.
Two ways for the details: The man page lists EINTR (and associated
description) as a possible errno value, implying that most any signal
would "fail" (i.e. interrupt/abort) the kevent() call, or you could
specifically wait for the signal to arrive by including an EVFILT_SIGNAL
filter (and presumably not get the "failure" errno setting).
In either case you probably need to register a signal handler - it
doesn't necessarily have to do anyting, just prevent the thread/process
from dying by its mere existence. Though possibly one of the "default to
discard signal" ones (see signal(3)) could work, at least for
EVFILT_SIGNAL.
--Per Hedeland
[email]per@hedeland.org[/email]
-
Re: Stopping a kqueue
Begin <2007012600111216807-anon@myspacecom>
On 2007-01-26, Bill <anon@myspace.com> wrote:[color=blue]
> My thread dedicated to the kqueue is basically a while-loop which
> blocks on the kevent() call until an event is posted, at which point it
> rattles through and does what it's supposed to. So far so good.[/color]
In addition to things said elsethread, I'm left slightly baffled as to
why you'd setup things this way.
You seem to be using kqueue for one feature only, where it is primarily
ment for another, the multiplexing. I'd say don't use a kqueue and a
thread just for monitoring one file, but make use of the multiplexing.
It is actually quite simple to use the cookie feature and fancy a
call-through from your driving loop to whatever function or object
you've setup to monitor the file.
[color=blue]
> I don't really want to set a timeout on the event blocking as that
> isn't really practical and it also turns it into a poll thereby
> defeating the purpose of using a kqueue in the first place![/color]
I disagree. The purpose is to provide an efficient de/mux interface for
events. It succeeds quite well in that, as long as you follow its model,
which you're trying not to. Instead you appear to try and fancy one-shot
constructions out of an interface that is ment to do much more.
--
j p d (at) d s b (dot) t u d e l f t (dot) n l .
This message was originally posted on Usenet in plain text.
Any other representation, additions, or changes do not have my
consent and may be a violation of international copyright law.