Software interrupts; where to start

[John Baldwin]

On Tuesday, November 16, 2010 12:08:51 pm Nathan Vidican wrote:
> What I would like to do, is replace the above scenario with one wherein the
> program writing to the serial port is always connected and running, but not
> polling; ideally having some sort of interupt or signal triggered from
> within memcached when a value is altered. Sort of a 're-sync' request
> asserting that the program sending data out the serial port should 'loop
> once'. I'd like to continue with the use of memcached as it provides a
> simple way for multiple systems to query the values in the array as well,
> (ie: some devices need not change the data, but only view it; given the
> latency requirements memcached operates ideally). This trigger should be
> asynchronous in that it should be fired and forgotten by memcached (by
> nature of the hardware designed, no error-checking nor receipt would be
> needed).
> 
> I'm just not sure where to start? Could someone send me the right RTFM link
> to start from, or perhaps suggest a better way to look at solving this
> problem? Ideally any example code to look at with a simple signal or
> interrupt type of handler would be great. What I'm leaning towards is
> modifying memcached daemon to send a signal or trigger an interrupt of some
> sort to tell the other program communicating with the device to re-poll
> once. It would also be nice to have a way to trigger from other programs
> too.

A simple solution would be to create a pipe shared between memcached and the 
process that writes to the serial port.  memcached would write a dummy byte to 
the pipe each time it updates the values.  Your app could either use 
select/poll/kqueue or a blocking read on the pipe to sleep until memcached 
does an update.  That requires modify memcached though.  I'm not familiar 
enough with memcached to know if it already has some sort of signalling 
facility already that you could use directly.

-- 
John Baldwin