>mmmmm that would be nice - though it's still useful during debugging to >be able to peer at the file times - if I used "job at" I haven't looked >into how to get a list of future 'pending events'.
On the systems I used (SVR2-4) it was via "atq". I think there were also options to "at" itself that would tell you what was scheduled. You could also dig it out of the files that cron left for itself in case of a system reboot. (The at jobs _would_ be executed, but late if the system were not actually running at the scheduled time. The periodic cron jobs would be skipped unless the system were running at the scheduled time.) >I hate polling too, but I feel the need to run shepherd and watchdog >functions, and that is inherently a sort of polling. It is. The trick is to be able to combine everything down to _one_ poll, and to keep that small. For example, relying on an underlying X.25 transport's keepalive function to notify you when a connection goes down, which gets propagated via read/write failure to _all_ clients using the transport, rather than burdening each and every user of the transport with its own heartbeat, as we had to do once when we moved a product from X.25 to IP WAN transports. (Bitter? Not I!) Minimize the polling to the absolute minimum, and convert everything else to event-driven. That's the secret to efficiency. The worst crons I've seen wake up every second and run their control file to see if there's anything to do. The best ones (and the original Unix one) calculate a delay list from the control file, and go to sleep until the next scheduled event. -- Jim _______________________________________________ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
