Bill wrote:
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 programmaticall y?
This is offtopic.
The general solution for event loops is to not block indifinetly (don't give
NULL as last argument to kevent) on waiting for an event but use a timeout
value that won't kill your CPU (so not extremly low) but will still provide
enough time resolution so that you can stop the loop in the timeframe you
need it (not very high). Example, my event handling loops timeout on 20
milliseconds which is enough that the CPU still shows ~0% usage if no
events are comming but still short enough that I can do several things that
are needed to be done at the same time (in your case just to exit ASAP). Of
course you will need to modify the code after the kevent call to be aware
that kevent now can also just timeout (return without any event) and this
is not an error.
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!
How come it turns it into a poll ? The big difference between poll(2) and
kevent(2) is not the timeout usage (hell, you can use no timeout for
poll(2) too thus it's the same thing) but the fact that poll(2) returns the
WHOLE structure back which you have to scan in liniar time for the events
while kevent always returns just the events thus the API itself is fast not
the function done in the kernel (I would expect both to do use some common
code up to some point). But if you mean it turns into a "poll" (as a
concept not the syscall) that's not right either. You are waiting for some
time to be notified about events and there are 2 cases:
1. almost no event will come in which case you will get a lot of timeouts
but this in reality doesn't result from any performance loss (if
implemented well), like I said, a 20ms timeout still makes my daemons show
as not using any CPU but sleeping most of the time which is what you want
to achieve right ?
2. a lot of events comming in which case the timeout is irrelevant as kevent
most of the time will return without timeout
I'm tearing my hair out, can anyone help please?
Next time, just look into any (open source) server handling event loop out
there and you will see most (if not all) of them using timeouts on I/O
multiplexing. I really fail to see what's your problem with that when it's
cleanly solving the initial problem.
--
Dizzy
http://dizzy.roedu.net 
