Hi,
On Tue, 22 May 2012, Julien Claassen wrote:
> feature - at least, I think, that it might be small. A pendant to stop-sync:
> start-sync, which only returns, until the engine is perfectly running.
'stop-sync' is (and 'start-sync' would be) actually somewhat hairy to
implement. The interface between user-interfaces and the engine is
asynchronous (due to the realtime<->nonrealtime boundary), so providing
synchronous services on top, requires a bit of work, and is prone to
errors. There is constant threat of missing some corner case, leading to
user-space never getting notfied (-> the ECI app calling
'sync-foo' blocked infinitely and never returns).
One clear complicating factor is that while there's only ever one engine,
multiple entities may be sending control message (JACK server, messages
over OSC, messages over MIDI, messages over ECI, etc). E.g. in the most
recent race discovered by S. Massy, the root problem in the end was that
"stop-sync" was not enough... what really was needed was a
"stop-sync-and-make-sure-nobody-can-restart-the-engine-unless-I-alone-specifically-give-the-permission"
command.
This is not rocket science either, but I'd rather keep the amount of
synchronous commands (towards the engine, chainsetup related commands are
always syncrhonous) to a minimum. Probably some more general way to wait
on events will be implemented sooner or later, that could be used to build
whatever synchronous needs on top. But that'll be quite a bit of work to
do, so not a short-term item.
What's your main use-case for 'start-sync'? I think a fairly workable
solution is just to busyloop on "engine-status" until it becomes "running"
(and then you can handle the special case yourself if state never gets to
"running" for some reason). I don't like 'stop-sync', but it had to be
added, as there was no reliable workaround for it...
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Ecasound-list mailing list
Ecasound-list@email-addr-hidden
https://lists.sourceforge.net/lists/listinfo/ecasound-list
Received on Mon May 28 00:15:06 2012
This archive was generated by hypermail 2.1.8 : Mon May 28 2012 - 00:15:06 EEST