From owner-freebsd-hackers@FreeBSD.ORG Tue Nov 16 18:20:10 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 74D181065696 for ; Tue, 16 Nov 2010 18:20:10 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id F2BC28FC1B for ; Tue, 16 Nov 2010 18:20:08 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 0E6A746B5C; Tue, 16 Nov 2010 13:20:05 -0500 (EST) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 30BB78A01D; Tue, 16 Nov 2010 13:20:01 -0500 (EST) From: John Baldwin To: freebsd-hackers@freebsd.org Date: Tue, 16 Nov 2010 13:19:58 -0500 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20101102; KDE/4.4.5; amd64; ; ) References: In-Reply-To: MIME-Version: 1.0 Message-Id: <201011161319.58787.jhb@freebsd.org> Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Tue, 16 Nov 2010 13:20:01 -0500 (EST) X-Virus-Scanned: clamav-milter 0.96.3 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.9 required=4.2 tests=BAYES_00 autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bigwig.baldwin.cx Cc: Nathan Vidican Subject: Re: Software interrupts; where to start X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Nov 2010 18:20:10 -0000 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