Not continuous, but the directory is polled. The only other sensible way around this is to use IPC or pipes, which is not
portable.
open the dir, select, and then readnext to see if there's a file item present. If so, delete it and process the request based on
that ID. You're basically popping off the 'stack'. If your configuration isn't saturated, polling ( or stack poppin) takes a
split-second to happen. It's not like there's 5000 items in the directory and you have to deal with select lag. I had one issue on
OpenQM/Linux, with the select polling. A 'loosey-goosey' loop ate up all the CPU ticks. A half-second NAP or SLEEP solves the CPU
problem, but it does reduce response time a tad. Adding another phantom will more than make up for that lag.
Sure, there are a zillion other ways to manage a queue stack. This is the most platform and flavor cross-compatible. If you have
another design suggestion that would work better, please let me know. Afterall, the project is GPL and needs some enhancing!
-Glen
Thanks for the reply. I wasn't critiquing so much as I'm curious: I was called in to accomplish this in a quick and dirty fashion 5 or 6 years ago and after a few days ended up with something very similar to what you describe.
I wasn't happy with a loop which continuously performed SELECTs but SLEEPs seemed to slow it down too much. I recall looking for something I could use as a blocking read operation and believe I tried pipes. IIRC they worked OK but sometimes operations hung up. I thought of using sockets but never had the chance to try. Perhaps you could get it to work with sockets and let me know what you find. :-)
Stewart -- Stewart Leicester | http://www.ThreatFocus.com V.P. Engineering | mailto:[EMAIL PROTECTED] Threat Focus, Inc. | 925-551-0130 Voice "Knowledge is your best defense" | 509-695-1373 Fax ------- u2-users mailing list [email protected] To unsubscribe please visit http://listserver.u2ug.org/
