Re: Asynchronous sockets?
Re: Asynchronous sockets?
- Subject: Re: Asynchronous sockets?
- From: Douglas Davidson <email@hidden>
- Date: Thu, 7 Feb 2002 11:46:48 -0800
On Thursday, February 7, 2002, at 11:10 AM, Duane Murphy wrote:
Sorry to bother you, but I have an additional question. There is an
implication here that CFSocket must be used with a run loop? Is this
true? It appears from the header file that the call back will get called
when data is available for reading.
I've not dealt with run loops yet, so I dont understand the
implications.
Basically can CFSocket be used without a run loop as a mechanism for
getting notified of socket data availability? (The Darwin CVS server is
unavailable or I would just read the source. :-)
The primary purpose of CFSocket is to provide a run loop source based on
a socket; it isn't much use without a run loop. I'm afraid that even
the source won't help you much in understanding what a run loop is for;
here's the five-cent tour:
Both Carbon and Cocoa applications are fundamentally event-driven; that
is, they are usually waiting for events (broadly defined) to arrive
(whether user-generated, or network-generated, or timer-generated).
They use a common mechanism for this: the run loop. You can also use
this mechanism yourself in things that are not Carbon or Cocoa
applications. The name "run loop" may not be terribly meaningful to
you, but what a run loop mainly does is to wait. It waits for something
to happen, then it notifies the application code, by calling a callback;
then when control returns to it, it waits again. This allows a single
thread to handle multiple event sources without polling.
The things-that-can-be-waited-for are described by run loop sources, and
they can be of a number of different types. There is precisely one run
loop per thread; any run loop can have many sources registered with it,
and a source can be registered with any number of run loops. In a
Carbon or Cocoa application, the application frameworks themselves run
the run loop in their main thread. If you are on a subsidiary thread in
such an application, or if you are writing something that is not a
Carbon or Cocoa application (e.g. a daemon) then you have to run the run
loop yourself if you want it to do its thing. Mainly this just consists
of calling CFRunLoopRun() and sitting back and waiting for things to
happen; the function doesn't return unless the run loop no longer has
any sources or is explicitly stopped, but usually you don't want that to
happen--you want it to keep going.
The main run loop sources at the CoreFoundation level are CFTimer (get a
callback at a specified time), CFMachPort (get a callback when a Mach
message arrives), CFMessagePort (a somewhat simpler and more abstract
local IPC mechanism), and CFSocket (get a callback when something
happens on a socket). Now, the callback can't happen unless the run
loop has control, so if you spend too much time in one callback then the
next one will be delayed until the run loop gets control again--these
aren't signals, and they don't have the problems of signals, but you
shouldn't expect any sort of real-time behavior from them.
The sample code I posted before shows the basics of creating a run loop
source with a socket and adding it to run loops, and running them.
There may not be a lot of documentation on this yet, but you can ask
questions on the mailing lists, and probably get an answer.
Douglas Davidson
_______________________________________________
macnetworkprog mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/macnetworkprog
Do not post admin requests to the list. They will be ignored.