event driven serial port handlers
djk at tobit.co.uk
Wed May 9 15:42:24 BST 2012
On 09/05/12 14:09, Mark Fowler wrote:
> On Wednesday, 9 May 2012 at 12:46, Dirk Koopman wrote:
>> My question is: is this going to be grossly inefficient bearing in mind
>> that I want to do this in a process that also serves the data in some
>> HTML5ish that allows me and others go "oo-ah" at the lovely webby guages
>> and graphs?
> Why is this happening in the same process? Couldn't you just store the results in some sort of database (or for that matter, simple flat file on disk.) The two separate processes you've got here (talking to the spottily connected weather station) and serving web pages seem like they'd better off being two, ahem, separate processes.
That's a point of view that I am considering. The answer depends rather
on the answer to the above question.
I didn't mention the UDP based data distribution protocol (or the
websockets) in the app, as that may have confused the issue.
As a multi protocol select()[ish] "event" handler is already involved,
and if it the character handling is not a big processor hog, then it
makes some sense to me to shove that in as another module serviced by
the "event" handler. I have quite a bit of form doing this sort of thing.
Having it in the same process, that then means arrival of data can drive
state changes which directly cause output such as sending stuff down
websocket connections and elsewhere via UDP. Otherwise one has to poll
databases, which is IMO naff (and a cop out in an "event" based
system)[and so is the "store it in a database and signal the main
Obviously, I could try it. But putting a framework together that I won't
have to throw away and start again is a significant piece of work. I was
hoping someone has the experience to answer my core question before
More information about the london.pm