event driven serial port handlers

[Dirk Koopman]

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 
process" model].

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 
plunging in.

Dirk