Stopping a kqueue - BSD

This is a discussion on Stopping a kqueue - BSD ; 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 ...

+ Reply to Thread
Results 1 to 4 of 4

Thread: Stopping a kqueue

  1. 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


  2. Re: Stopping a kqueue

    Bill wrote:
    >
    > 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?


    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(; { .....
    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


  3. Re: Stopping a kqueue

    In article <2007012600111216807-anon@myspacecom> Bill
    writes:
    >
    >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?


    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
    per@hedeland.org


  4. Re: Stopping a kqueue

    Begin <2007012600111216807-anon@myspacecom>
    On 2007-01-26, Bill wrote:
    > 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.


    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.


    > 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 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.

+ Reply to Thread