10-24-2012
4,673,
588
Join Date: Oct 2010
Last Activity: 1 February 2016, 3:35 PM EST
Location: Southern NJ, USA (Nord)
Posts: 4,673
Thanks Given: 8
Thanked 588 Times in 561 Posts
Polling is an architectural choice. If the originators have a subscription list or a common destination, they can push. Polling is about pulling information that may not exist yet. Then there are signals, which shells can send with kill and receive with trap. Two signals are reserved for app use. Signals allow for interrupt driven processing, which is a sort of push, in that the originator pushes a signal. The master can process signals one at a time so no chaos erupts. However, the signal is pretty bare, does not tell you who is calling, so you need a per sender message file, even as just a flag, that is only polled on interrupt. That's nicer than polling in a tight loop wasting and destroying resources, or sleeping and ignoring new data. There is often a little poll under an interrupt. You could have the message files be queued in a special directory, named uniquely, so on interrupt the master processes each and then deletes it. The file name or content may just tell the master where to go for the full message, or may be the full message. Files can be composed elsewhere on that file system or in that dir but with a filtering extension, and mv'd when complete, so there is no race condition. Directories provide all the necessary locking and list management for multiple simultaneous writers. Exploit them.