Re: OTCreateSystemTask() Replacement?
Re: OTCreateSystemTask() Replacement?
- Subject: Re: OTCreateSystemTask() Replacement?
- From: Josh Graessley <email@hidden>
- Date: Sat, 7 Apr 2007 20:26:59 -0700
On Apr 7, 2007, at 7:59 PM, email@hidden wrote:
On Apr 7, 2007, at 8:21 PM, Josh Graessley wrote:
Are you trying to develop for Mac OS X or Mac OS 9?
For Mac OS X, you should seriously consider switching to a
CFRunLoop and using sockets and CFSocket to handle networking.
NewThread, OTCreateSystemTask, WaitNextEvent, SystemTask are all a
compatibility shim to keep old code limping along. They are not
intended for new code development.
This is for OS X. I started working on networking back in the 90s
when it was still a nightmare on the Mac, so it messed up my
methodologies. Now I am just calling sockets directly, but the
problem is really logistics now since I have a udp class that needs
to have its Idle() function called periodically for polling. It
has several dozen functions so it's not feasible to make the whole
thing preemptive. For example, it would just die right now if I
called Idle() from another preemptive thread. It should be
perfectly legal to call Idle() during a dialog's system task time
though. Such a thing should still exist on the mac, since
countless programs bring up dialog boxes in their main thread. If
it doesn't, then it got axed for political reasons and I just don't
know how much more of that I can take.
I guess what I am trying to say is, if the notion of system task
time doesn't exist anymore, then we can't really write nonblocking
code on the main thread that can coexist with system gui elements.
I think that's a big deal, and I hope that there is a way to do it.
You need to grab a book on OS X. The cooperative/preemptive threads
of yesteryear are gone. Mac OS X has a frightening compatibility
layer that attempts to emulate some of this behavior for old code.
Don't use it. You will run in to buggy behavior and you won't find
anyone that knows how to help you diagnose problems. It's time to
learn about how things are done in Mac OS X and refactor your code to
do the right thing.
There is no such thing as a cooperative thread anymore. Mac OS X uses
run loops. They're like the old Mac OS 9 event loop except that
WaitNextEvent is called for you once you call CFRunLoopRun or
whatever it's called. You just have to register for events you're
interested in and handle those events in the callback you supplied.
It's great. Use it.
Slightly off topic, but....
You only need to use multiple threads if:
1) You're compute bound
2) You're stuck using a broken API
For the first example, if you are doing some mathematical calculation
or something cpu bound like encoding video, you can take advantage of
multiple cores by spawning multiple threads.
For the second example, consider the way that CFSocket works. The
run, deep down inside, is the mach equivalent of select on multiple
ports. There is no way to do a select across mach ports and file
descriptors (sockets). CFSocket works around this by creating a
second thread. The second thread calls select on all of the sockets
registered with a CFSocket. There is one extra file descriptor that
the thread running the run loop can use to communicate with the
CFSocket thread. In addition, there is a mach port that the CFSocket
thread uses to wake up the CFRunLoop thread. The interaction is
tricky, so it's nice someone else has done all the work. In this
particular case, the additional thread was required simply because
the existing APIs presented no other way to add a socket or file
descriptor to the list of things that generate events that the run
loop is waiting on. This is a dream of kqueues some day eliminating
the need for this additional thread by filling in the missing API.
Blindly adding threads to code doesn't make it execute any faster,
but it often makes it crash a whole lot quicker.
-josh
P.S. Whatever happened to Return to Dark Castle?
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________
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