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: Quinn <email@hidden>
- Date: Thu, 5 Mar 2009 16:00:51 +0000
At 10:42 -0500 5/3/09, Peter Sichel wrote:
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.
True. Although I just discovered that NSFileHandle's background mode
uses a thread per file handle, which in another nail in its coffin as
a networking API IMO.
Once these issues are abstracted out of developers programs, the
system software is free to improve the underlying mechanism
transparently.
Again true.
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.
I wouldn't say that either of these is completely true, at least not
yet. Certainly, CFSocket extracts a performance penalty on current
system software and, if you're goal is the absolute best performance,
dropping down to the BSD sockets level is definitely the best choice.
Of course, in The Future (tm) (specifically the "Grand Central"
future <http://www.apple.com/macosx/snowleopard/>) this may change,
but I'd be reticent to draw any solid conclusion until this future
becomes a reality.
S+E
--
Quinn "The Eskimo!" <http://www.apple.com/developer/>
Apple Developer Relations, Developer Technical Support, Core OS/Hardware
_______________________________________________
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