On Nov 7, 2007, at 4:37 AM, Frank Barknecht wrote:
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
Pre-emptive threads are by their very nature non-deterministic because there is no way to guarantee that the things in different threads will execute with the same order everytime. Yes, the order that you send the messages won't change if you have one thread for the message sending, but once you have the thread, you can't guarantee that the database will return it's answer within on logical Pd clock tick. Pd/Max is built around this idea, that each object does it's thing within one clock tick.
I wonder, what use is a database result if it comes five minutes after I sent the retrieval command? The only use for such an object would be to slowly fill another container like [textfile], which has guaranteed, deterministic response time. OTOH if a db-object would be allowed to send results to its outlets non-deterministically, it would be useless as a replacement for deterministic containers like [textfile]. So we'd need to versions of that db-class, either two classes or one class with a switch. I think, the deterministic version is more useful, and if you use a fast/local DB, it's about as reliable as hard disk access or netreceive.
AFAIK, MySQL and the like do not guarantee realtime responses, and network connections certainly do not. So if want something that is designed to do that, then use [pool], [textfile], or perhaps an embedded SQLlite, if it is quick enough.
Unless there are ways to guarantee the database will reply within one clock tick (usually ~1.5ms), then the interface should represent the reality of the situation. Otherwise the database object will cause lots of clicks and interruptions when used.
.hc
Ciao
Frank Barknecht _ ______footils.org__
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
------------------------------------------------------------------------ ----
Mistrust authority - promote decentralization. - the hacker ethic