Re: [Chicken-users] Re: An alternative thread system?

[john]

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 <address@hidden>:
> On Mon, 11 Aug 2008, Aleksej Saushev wrote:
>
>> Ivan Raikov <address@hidden> 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
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/chicken-users
>