Re: Cancel printer network connection
Re: Cancel printer network connection
- Subject: Re: Cancel printer network connection
- From: Quinn <email@hidden>
- Date: Wed, 9 Dec 2009 11:59:14 +0000
At 09:40 +0800 9/12/09, Peter C wrote:
I have a basic LPR code with socket (blocking) for sending printer
file directly to printer. The code works fine, now I want to add a
cancel feature (cancel button on the GUI) . When data is write to
socket, it is block, not able to abort. How do I go about it ? I
read the SocketCancel sample code but it is using non blocking code.
Cancellation is one of my "Five Reasons Why Synchronous Networking Is
Bad" (see below for the full list). Your choices are:
A. do something crazy with inter-thread signals -- I recommend
against doing this. Signals are even more evil that threads, and
signals /with/ threads is evil squared (-:
B. switch to fully asynchronous -- This is the solution I generally recommend.
C. pseudo-synchronous -- SocketCancel is an example of this. It uses
asynchronous APIs under the hood, but it looks synchronous to higher
level software.
It sounds like your building this code into a GUI application. In
that case I'd recommend B. If that's not to your liking, C should be
fine.
S+E
--
Quinn "The Eskimo!" <http://www.apple.com/developer/>
Apple Developer Relations, Developer Technical Support, Core OS/Hardware
* * *
Five Reasons Why Synchronous Networking Is Bad
==============================================
When you do networking, you have a choice of three different modes:
o asynchronous -- For example, you can schedule an NSStream on a
runloop and have it call you when data arrives.
o synchronous, polled -- For example, you can periodically call
-[NSInputStream hasBytesAvailable] to see if data is available.
o synchronous, blocking -- For example, you can just call
-[NSInputStream read:maxLength:] which will block if no data is
available.
In virtually all cases I recommend that you use asynchronous
networking. That's because the other two options have fundamental
pitfalls, as explained by the rest of this document.
To start, it's obvious that polled mode is bad: it forces you to
choose between wasting CPU time or wasting network performance. If
you poll frequently then, on a slow network, you will be wasting CPU
time (and thus power, which is obviously an issue on mobile and
notebook hardware, but has recently become an issue on desktop and
server hardware as well). If you poll infrequently then, on a fast
network, you will be squandering network performance.
It's less obvious why synchronous blocking networking is bad. Each
of the five sections below describes a serious problem with it.
1. Resource Usage
-----------------
The number one reason synchronous blocking networking is bad is that
it wastes resources. You can't do synchronous blocking networking on
the main thread, so you necessarily have to create a secondary thread
to do the work. That thread is a waste of resources, most notably:
o virtual address space (always consumed)
o a /wired/ kernel stack (consumed while the thread is blocked)
This is especially bad when you're handling lots of connections
simultaneously, most of which are idle. You consume a bunch of wired
kernel stacks to get exactly /no/ work done.
2. Threads Are Evil
-------------------
Because synchronous blocking networking requires a secondary thread,
you have to deal with having multiple threads in your process. This
raises a host of thread-related issues, most notably the problem of
sharing data between threads. It's best to avoid this if you can.
3. Cancellation
---------------
Synchronous blocking networking makes it very hard to support
cancellation. You either have to jump through a bunch of hoops (see
my SocketCancel sample) or poll for cancellation (and did I mention
that polling was bad?).
<http://developer.apple.com/samplecode/SocketCancel/index.html>
4. Timeouts
-----------
Implementing a timeout is tricky with synchronous blocking
networking. Some synchronous blocking APIs implement some form of
timeout support, but not all. And where they do, the support tends
to be less robust than you'd like.
Again, you can work around this with various tricks but this serves
to further undermines the illusion that synchronous blocking
networking is easier.
5. Bidirectional
----------------
It's not possible to support full bidirectional communications on a
single synchronous blocking connection.
* * *
_______________________________________________
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