> On Mon, 12 Jul 1999, Alex Belits wrote:
>
> > On Mon, 12 Jul 1999, Mike Harrelson wrote:
> >
> > > They may be harder to debug, but that doesn't mean we should just throw
> > > them out.
> >
> > Throwing them out will be pointless, but overuse of threads is harmful.
Overuse of anything is harmful.
So is underuse.
> > The fact that in certain other OS nothing can be accomplished efficiently
> > without them is irrelevant.
Then why keep bringing it up?
> > > Threads can and do make many applications much easier to design and
> > > implement without having to go to a slower process/fork()
> >
> > It's noticeably slower only if processes are constantly created -- but
> > the same applies to threads.
Slower is the wrong argument. Often threads make for a *much* cleaner
design. I've actually implemented thread-like libraries for DOS just
because of this.
> > Unix has more advanced interprocess communication than ones in other
> > systems precisely because it does not rely on threaded programming.
>
> And also because most Unix IPC were developed before threads were even
> thought about. I don't know much about IPC on other systems (like NT) so I
> can't comment about it being more advanced.
Umm, Unix has more advanced IPC than exactly *which* other system? DOS?
I've yet to discover any advanced IPC in Unix. Old and clunky is a better
description. (Of course, that doesn't mean certain other systems can't
manage to do advanced and clunky.)
I wouldn't point to Win32 IPC as a shining example, but Unix could
certainly learn a number of things from it.
If you thing Unix IPC is so great, then try to count the cases of *real*
IPC (that is, more than just starting another process with output
redirection) in your system. I'll be astonished if you need two digits.
Let's see, there's X, there's the resolver, maybe there's a database like
Postgresql, maybe you want to count POP3 or NNTP (incidentally, each of
those uses *networking* to do IPC) - oh yes, screen or xterm or similar if
you use it, at least that's using ptys. And there's device lockfiles and
daemon pid files. That's about it.
Unix is great, but IPC is not why.
I've thought about what would be involved in writing something like the
AppleEvent/AppleScript stuff - somewhat more reasonable, IMHO, than doing
ORB stuff, with ILU or IDL. The first question is, what IPC mechanism do
you base it on? How do programs find each other's communications ports
(whatever those are implemented like)? There's not even a portable
mechanism for enumerating processes, and there's nothing you can do with a
pid except send a signal (which is lousy for IPC). So programs need to
register somewhere. Either in some directory or with some server. Sure,
that's all *possible* - but compare it with MacOS or Win32 (or, I'm sure,
plenty of other systems), where of course you have a mechanism for
enumerating processes, and where there's a standard event mechanism you
can use for doing your IPC.
MfG Kai
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/