Concurrency, was Re: Doh! Stupid Programming Mistakes <humor>
bryan.sant at gmail.com
Fri Oct 27 12:50:49 MDT 2006
On 10/27/06, Shane Hathaway <shane at hathawaymix.org> wrote:
> Your argument for threads is retarded. You're still assuming that you
> actually have control over the scope of all variables, but future
> maintainers will simply add the "static" keyword to one of your
> variables, breaking your model. This is no fantasy; I've seen bright
As does your model. You're saying that using a protocol and IPC, that
you avoid these same issues. That's not true. You still have this
issue where a new developer could expose something in one process that
you don't want accessible in another. This isn't any harder than with
a threading model. You could say, "Well, that wouldn't likely happen
because we have a convention/protocol." Well, I have a convention
too. I'm just saying that it's apples-to-apples as far as risk of
exposing problems is concerned.
When working with threads or inter-process-communication, sharing data
is a *liability*. You only share the data that you absolutely have
to, and that data is protected by sane locking. Likewise, you would
do the same thing with your IPC -- only expose what you want exposed.
But some Jr. Developer could accidentally expose data via the
protocol, just like someone could make something static (global) with
threads. The risk exists in both solutions, but your solution has
additional down-sides that are significant.
> programmers do just that. Or someone like me will come along and try
> very hard to understand your model, but then extend your model in a way
> that introduces subtle but nasty bugs. And it will cost a whole lot to
> fix the mess.
You would have this same problem. I wouldn't understand your model,
and then decide that I want to expose all kinds of shared data via
your protocol that you never intended to be exposed. Processes + IPC
is no better or worse. It's just slower at sharing the data.
> Look at the rise of web services. Web services are little more than IPC
> across multiple machines. Apparently people find value in the concept.
> I'm sorry you don't.
Ahhhh. Now you're making a valid argument. A true benefit of using
separate processes (on different boxen). However, now we're talking
about RPC and distributed computing not IPC. You're preaching to the
choir concerning RPC and distributed computing.
> Now, don't forget this is a humor thread. This argument is for fun; in
> reality, you're exactly right WRT some kinds of problems.
If it's for fun, it ain't PLUG ;-).
More information about the PLUG