In terms of IPC, if you are a not worried about getting too high level there is D-Bus. It uses a binary protocol so is not sending bloat and was originally designed to run within the same machine. I guess it is Linux-centric but is popular on GNOME, KDE and now on mobile Linux initiatives.
John. 2008/8/11 Elf <[EMAIL PROTECTED]>: > On Mon, 11 Aug 2008, Aleksej Saushev wrote: > >> Ivan Raikov <[EMAIL PROTECTED]> writes: >> >>> I agree that message-passing in general can be made as >>> incomprehensible and non-deterministic as threads. So one should >>> carefully choose their message-passing abstraction. But for example >>> Unix pipes guarantee that messages between two processes will be >>> received in the same order they are sent, which is already a much >>> stronger guarantee than what you get with threads and their >>> do-it-yourself approach to synchronization. >>> >>> So even an abstraction as simple as pipes already hides a lot of >>> complexity that shared-memory designs have to deal with explicitly. If >>> you look at Erlang, which is a language designed to be concurrent at >>> the core, its principal concurrency abstraction is message-passing, >>> not shared memory. Not to mention that most research efforts into >>> concurrent languages ended up devising process calculi with much, much >>> stronger determinism than shared-memory concurrency. >>> >>> The moral of the story is that systems whose behavior is governed >>> by an explicit, unchanging set of states and transitions is much >>> easier to reason and think about, than are shared-memory systems whose >>> behavior may be determined by instruction timing-- something that the >>> programmer has no control over, and cannot monitor other than with >>> very sophisticated debugging tools. Message passing can provide this >>> explicit determinism, while shared-memory threads might be able to do >>> so only at the expense of very complicated (and slow) locking >>> semantics. >> >> The point is, threads are not complex to debug, what is complex >> is shared access to memory, which you can easily avoid. >> Pipes are not that simple actually, to pass some complex structure >> through pipe, you need to pack it to some structure on one end, >> parse and unpack on the other end (note all those XML/YAML encodings), >> while with _some_ shared memory you could just pass the reference. >> >> Again, the problem isn't in threads or shared memory, it is in >> abstractions used. It is like modular programming vs. the >> ancient non-modular one (with lots of shared variables &c). >> > > Disagreed absolutely. Threads can be incredibly complex to debug, even > ignoring shared memory issues. Threads can get stuck in dependency loops > very quickly while waiting on I/O, even from possibly different sources. > Threads can get interrupted in all kinds of unpleasant ways without being > detectable as such. If you're the sort of person who uses a debugger (I'm > not), to the best of my knowledge no debuggers handle multithreaded software > particularly gracefully. You don't need all the XML/YAML/Whatever-This- > Months-Buzzword-Is. It's pretty trivial to define a small, customised > format for messages in your application. It's also easy to add sanity > checking to messages, so the receiver can detect if the sender is in an > inconsistent state (or if the message was, at very least) and try to correct > for it. It's easy to add new message capability to the system with a new > process handling it, because its a lot more loosely coupled. It's easier > to keep data formats small. The potential for race conditions is greatly > diminished if the implementor was not a total idiot about security. The > flow of the program is deterministic and verifiable. This last condition > is not possible, to the best of my knowledge, in threading systems, without > having the scheduler be so restrictive and have so much information about > everything beforehand that it essentially runs as a single-threaded program. > > -elf > > > > > _______________________________________________ > Chicken-users mailing list > [email protected] > http://lists.nongnu.org/mailman/listinfo/chicken-users > _______________________________________________ Chicken-users mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/chicken-users
