Re: Wise? Stupid? Somewhere in between? Thinkin' out loud...
Re: Wise? Stupid? Somewhere in between? Thinkin' out loud...
- Subject: Re: Wise? Stupid? Somewhere in between? Thinkin' out loud...
- From: Dakidd <email@hidden>
- Date: Sat, 17 Jul 2004 02:07:18 -0700
>
At 23:19 -0700 13/7/04, Dakidd wrote:
>
>Ideally, I want to call ReadFrom(ConnectionRef, Buffer, BufferLength) and
>
>get back either a positive number indicating the number of bytes read into
>
>the buffer, a zero (Nothing available, try again later) or an OSStatus to
>
>signal an error. Blocking is to be avoided if at all possible - No data on
>
>this connection? Go deal with something else until some arrives.
>
>
Right. This is basically a polled API, and you can implement that
>
trivially using OT. Just put the endpoint into a non-blocking mode
>
(that is, anything except sync/blocking), and OTRcv works pretty much
>
like this.
erm... Kinda... Except I'm wanting to do the network IO stuff
asynchronously, and have it being handled within its own thread. (The meat
of the thread is a "did Connection[0 < x < MaxThreads] get an OT event? It
did? Service that event. Or it didn't? Check the next one." loop, with a
YieldToAnyThread() happening each time x hits MaxThreads
One of the things I'd LIKE to do, if I can figure out an effective method,
is turn an asynchronous OT event notification (T_Data, etc) into a Carbon
event. I have at least a basic concept of how to do this, at least in terms
of the mechanics of defining, issuing, and handling such a "synthetic"
event. It's just figuring out the details of exactly how I want to do it
that needs to happen.
Which brings up another point - I can't find a definitive "The main event
loop does/does not call YieldToAnyThread() (or does/does not do something
equivalent) that will let my threads have time" statement. Perhaps I've
looked through it. Perhaps it doesn't exist. Idunno... You got any
information on that score?
At present, I'm going with the concept of "If the OT event code IS
OTSyncIdle, the notifier does a YieldToAnyThread(), otherwise, the notifier
stuffs the information it gets handed into the struct passed as the context
pointer, then exits, leaving "NetworkServicingThread()", which as the name
implies, is a separate thread that services OT notifications, to deal with
doing whatever it is that needs to happen in response to a particluar event
code. I'm running into weirdness with how to make certain that SOMETHING is
going to yield so that the servicing thread can run.
>
Using a polled API is simple enough, but it doesn't translate well to
>
modern platforms (even modern versions of traditional Mac OS). I go
>
over this in some detail in the OTMP readme.
>
>
<http://developer.apple.com/samplecode/OTMP/OTMP.html>
The .sit is downloading as I type this, and I'll definitely put an eyeball
over it when it arrives.
>
You basically have a choice. You can either poll frequently, in
>
which case you burn CPU cycles (and battery life on a portable), or
>
you can poll frequently, in which case you set an upper bound on your
>
transfer speed. If you're writing a specific application, you can
>
use application-specific knowledge to determine the polling rate.
>
For example, a program that uses networking just to see if a new
>
update is available can poll at a very low frequency, because the
>
bandwidth is very low. However, if you're writing a generic library,
>
you have to come up with some general solution. This is not easy,
>
especially if you need to deal with traditional Mac OS (where
>
WaitNextEvent pretty much forces you into a polled model).
>
>
If I was in your situation (programming for my own hardware, stuck on
>
traditional Mac OS), I'd seriously explore OTMP.
I'm not really targeting "traditional" MacOS, although if I can make it
happen that way, it would be a welcome bonus -I'm looking to be carbon
compliant, or as much so as possible, given the environment I'm force to
work within.
Don Bruder - email@hidden <--- Preferred Email - unmunged
I will choose a path that's clear: I will choose Free Will! - N. Peart
_______________________________________________
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.