Thread: 2^1466L done
View Single Post
Old 2006-03-01, 09:59   #7
Jushi's Avatar
Sep 2005

1111002 Posts

Originally Posted by Wacky
It is more difficult than you think. Because of I/O buffering and "GUI" event loops, you cannot simply "abort" a running thread. In most (OS) cases, you end up having to "poll" to determine if the program should stop. The cost of polling is not insignificant. Therefore, you do not want do do it too often. Finding an appropriate location within the nested loops my not be easy to do.
If it is too low, not only do you waste the time polling, but you may also invalidate the caches, adding even more overhead. On the other hand, if the polling is done too far out, it may not be frequent enough to give satisfactory response. Considering that the length of a "line" may vary by a couple orders of magnitude, finding the right balance is not trivial.
I don't know about Windows, but in Unices all this can be done quite easily using signals. You could have one process (nfsnetclient) doing the polling for stop.txt and sending a signal to the linesiever to stop it. The linesiever can then catch this signal to gracefully quit, but maybe this isn't even necessary. Maybe you can simply "abort" a running linesiever.

I know that Linux even has a mechanism using signals to notify when a new file is created in a directory, so then you don't even need to poll for stop.txt (this is probably Linux-specific).
Jushi is offline