Re: Five Reasons Why Synchronous Networking Is Bad
Re: Five Reasons Why Synchronous Networking Is Bad
- Subject: Re: Five Reasons Why Synchronous Networking Is Bad
- From: email@hidden
- Date: Thu, 05 Mar 2009 09:20:49 -0700
On Mar 5, 2009, at 8:42 AM, Peter Sichel wrote:
Great write-up, thanks!
On Mar 5, 2009, at 7:32 AM, Quinn wrote:
o asynchronous -- For example, you can schedule an NSStream on a
runloop and have it call you when data arrives.
Of course scheduling a CFSocket on a runloop must also use a thread
to work around the current Sockets API, but this single shared
thread is carefully optimized and integrated with Mac OS X by a team
of specialists. Once these issues are abstracted out of developers
programs, the system software is free to improve the underlying
mechanism transparently.
So part of the argument here is that 3rd party developers should
avoid select() and similar mechanisms when possible since higher
level CFSocket based abstractions are more robust and efficient.
The larger implication is that a generation of network software
developers who grew up on UNIX BSD APIs (like me) will need to be
coaxed into rethinking their network programming abstractions.
Just thought that I'd throw something else out there: traditional
networking education has been disastrous for programming large scale
projects. For example, notice that nearly all web browsers still
block and spin the beachball while loading a page. Quite simply, most
networked apps today are programmed incorrectly for the tasks they
perform. They may use server methodologies when they are clients,
they may optimize throughput over latency or do any number of things
that are fragile, resource hungry and difficult to maintain.
It's easier to begin programming with sync blocking, but that leads
down the path that Java has chosen, basically bloated and complex
projects riddled with race conditions and other hazards. I actually
started with async programming under OpenTransport, and then moved to
state machines, then to more traditional threaded/blocking code to
handle a large number of states. None of which can handle the
complexity of even a conceptually "simple" application like Adium.
Today's apps can't have even a single bug or they are considered
unusable. That largely rules out both state machines and threads.
After coming full circle, I have to say that my favorite way to handle
multiple event streams is to use an event-based system similar to
NSStream and runloops. Then, I use cooperative threads to avoid the
use of state machines. For example, to handle an IRC chat, one can
step through each phase of setup and teardown in a series of simple
yielding wait loops in a cooperative thread. This is also known as a
coroutine, something that has fallen out of favor but IMHO needs to be
brought back and taught in schools. The main loop can put coroutines
to sleep or wake them up as needed, so they're a nice compromise
between blocking and polling.
I also wish we had a construct for in-process processes. In other
words, we need threads that don't have global variables, so that all
state is passed through messages. This sounds strange at first, but
it really is the only way for beginners to avoid the numerous pitfalls
that experienced network programmers have trouble explaining.
Troublesome notions like mutexes and critical sections can be largely
avoided this way. Especially if the threads are cooperative instead
of preemptive. Most web-style programming is conceptually simple and
won't suffer efficiency losses with this system, and will perform in
the way people expect.
Just my two cents :-)
--Zack
"We are all failures -- at least, all the best of us are."
--Sir James M. Barrie, British Playwright
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Macnetworkprog mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden