Ivan Raikov [EMAIL PROTECTED] writes:
Guys, I am glad to see that old flame wars never die ;-)
Yes, but I have no time to participate in them today, hence I quit.
Pipes used to be slow back in the day, around the time when
forking and context switching was slow.
Context switch remains to
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 13 Aug 2008, at 7:29 am, Aleksej Saushev wrote:
Ivan Raikov [EMAIL PROTECTED] writes:
Guys, I am glad to see that old flame wars never die ;-)
Yes, but I have no time to participate in them today, hence I quit.
Pipes used to be slow
Well, I think your lengthy reply would be a useful contribution to
this discussion, so you should try to finish it. The issue of threads
is an ongoing conversation on this mailing list, so there is no time
limit for responses.
-Ivan
Aleksej Saushev [EMAIL PROTECTED] writes:
I have
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 12 Aug 2008, at 4:13 am, Ivan Raikov wrote:
Guys, I am glad to see that old flame wars never die ;-) Pipes used
to be slow back in the day, around the time when forking and context
switching was slow. Nowadays, modern kernels rely
Am Montag, den 11.08.2008, 10:25 +0400 schrieb Aleksej Saushev:
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
Am Montag, den 11.08.2008, 13:44 +0900 schrieb Ivan Raikov:
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
I agree absolutely.
Actually I'm
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.
Elf [EMAIL PROTECTED] writes:
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
On Mon, 11 Aug 2008, Aleksej Saushev wrote:
snip
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
I'm inclined to agree with the argument that as long as forking has a
low enough overhead, processes are better than threads for
general-purpose parallelism. Especially considering that if you are
using memory to share state between threads, you will always be
limited to a shared-memory
Elf [EMAIL PROTECTED] writes:
On Mon, 11 Aug 2008, Aleksej Saushev wrote:
snip
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
Aleksej Saushev scripsit:
Have you ever used operating system with no MMU? Processes and
threads are the same in relevant parts here. There's no
difference in behaviour of multiple processes and multiple
threads, in both cases you see deadlocks, races and contention.
All relevant mechanisms
On Mon, 11 Aug 2008, Shawn Rutledge wrote:
However what about the case where there is a UI event loop and the
same program also has to poll one or more event sources, such as dbus,
or a socket or a pipe, for output from one of those helper processes
that you redesigned to be a process rather
Shawn Rutledge [EMAIL PROTECTED] writes:
I'm inclined to agree with the argument that as long as forking has a
low enough overhead, processes are better than threads for
general-purpose parallelism. Especially considering that if you are
using memory to share state between threads, you will
On Tue, 12 Aug 2008, Aleksej Saushev wrote:
Elf [EMAIL PROTECTED] writes:
On Mon, 11 Aug 2008, Aleksej Saushev wrote:
snip
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
On Tue, 12 Aug 2008, Aleksej Saushev wrote:
Shawn Rutledge [EMAIL PROTECTED] writes:
I'm inclined to agree with the argument that as long as forking has a
low enough overhead, processes are better than threads for
general-purpose parallelism. Especially considering that if you are
using
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Some people wrote:
[Threads are a pain, much better to stick to message passing]
Some other people wrote:
[But but but processes communicating with pipes is the same as
threads using message passing primitives]
Well, yes. To a certain extent,
On Mon, Aug 11, 2008 at 2:39 PM, Aleksej Saushev [EMAIL PROTECTED] wrote:
Your attitude to threads is just a prejudice with no support behind it.
I'm not completely afraid of threads, I've used them. (Have
experienced some of the usual problems with using them, too.) I'm
just trying to justify
Guys, I am glad to see that old flame wars never die ;-) Pipes used
to be slow back in the day, around the time when forking and context
switching was slow. Nowadays, modern kernels rely extensively on
zero-copy techniques, and I am pretty sure that Linux has had
zero-copy pipes since at least
19 matches
Mail list logo
