Proper usage of OTAsyncOpenEndpointInContext()
Proper usage of OTAsyncOpenEndpointInContext()
- Subject: Proper usage of OTAsyncOpenEndpointInContext()
- From: Dakidd <email@hidden>
- Date: Wed, 9 Jun 2004 20:13:37 -0700
After getting things more or less functional in my app, I decided to go
from the synchronous, to the asynchronous model for handling networking.
But I've hit a snag. And now that I've spent some time beating my head
against it without success, maybe I need some fresh eyes looking at the
code. Maybe I'm looking "through" the problem without realizing it? Maybe
I've got tunnel vision from trying to spot it for so long? Maybe something
else? Whatever the cause, if you can see what's wrong here, and even
better, how to fix it, you're doing better than me! I'm targeting Carbon
under MacOS 9.1 (No OS X capability for now)
Here's the definition behind the "ThePeer" variable that's used in the code:
typedef struct PeerListEntry
{
char Address[255]; // Remote address (As either a dotted IP
or domain name)
InetPort Port; // The remote port number to try to talk on
InetAddress ResolvedAddress; // OT's representation of a resolved address
PeerFlags Flags; // My flags for the peer's status/settings
OSStatus Error; // What was the last oops?
EndpointRef Endpoint; // The Endpoint reference for this peer
TEndpointInfo EndpointInfo; // and the info that goes with it
TBind TBindIn; // structs for OTBind() calls
TBind TBindOut;
TCall SndCall; // TCall structs that will be needed for
I/O work with this peer
TCall RcvCall;
ThreadID ServicingThread; // Not used. Yet...
Handle InBufHandle; // Handles to the I/O buffers we'll be using
Handle OutBufHandle;
unsigned char *InBuf; // The dereferenced buffers
unsigned char *OutBuf;
} PeerListEntry;
typedef PeerListEntry *PeerListEntryPtr;
And here's the code itself, stripped down to what I believe are the
absolute barest of bare essentials to save space.
void InitNewPeerListEntry(PeerListEntryPtr ThePeer)
{
OTOpenFlags MyOpenFlags = (OTOpenFlags) 0; // Use defaults.
OTNotifyUPP MyNotifierUPP = NewOTNotifyUPP(MyAsyncOpenEndpointNotifier);
OSStatus OEICResult = noErr; // Forever the optimist...
// Some setup stuff snipped. At least in theory, none of it
// should matter to this problem.
// Experimentally confirmed - With the OTAsyncOpen...() call moved
// ahead of everything else that was before it, the problem remains.
OEICResult = OTAsyncOpenEndpointInContext(OTCreateConfiguration(kTCPName),
MyOpenFlags,
&ThePeer->EndpointInfo,
MyNotifierUPP,
(void *)ThePeer,
Globals.OTContext);
if (OEICResult != noErr)
{
// cope with error - code snipped for space/clarity
}
else
{
// More initialization of the PeerListEntry that ThePeer points to.
}
// error recovery/graceful exit snipped for space
}
When ThePeer first arrives, it might very well be nothing more than a
pointer to enough space (gotten from NewHandleClear(), moved high, locked,
and dereferenced) to hold a PeerListEntry. By the time things hit this
code, anything that's involved in creating an endpoint has *SUPPOSEDLY*
been initialized to a sane default value, and it's time to actually go
ahead and create it. The notifier routine, MyAsyncOpenEndpointNotifier(),
is still just a stub, but things go fatally bad long before that ever gets
a chance to come into play.
The OTAsyncOpen...() call pukes, first time, every time, with an unmapped
memory exception. Heaps are fine (according to MacsBug), and everything I
can think of to look at has been looked at, tinkered with, worried over,
poked at, breakpointed, and otherwise examined to death, and appears to be
anything *BUT* a problem - Everything that looks like it should have any
effect on the OTAsyncOpen...() call's operation appears to be exactly as it
should be just prior to the call. After the call bombs with the unmapped
memory exception, everything that I can look at (I wish CW's debugger
didn't send the program and variables to la-la-land after catching a
"bomb-worthy" problem the way it does, but... "If wishes were fishes, we'd
walk on the seas", right?) still looks just fine.
So maybe *YOU* can see the problem? I hope so, 'cause it's doing a real
good job of hiding from me!
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.