FW: Proper usage of OTAsyncOpenEndpointInContext()
FW: Proper usage of OTAsyncOpenEndpointInContext()
- Subject: FW: Proper usage of OTAsyncOpenEndpointInContext()
- From: Mark Thomas <email@hidden>
- Date: Thu, 10 Jun 2004 11:42:28 +0100
- Organization: Coderus Ltd
Hi,
I'm guessing that OT got initialized with the context you created and that
Create have a valid Context for OT to use, which you created before hand, as
I'm guessing that's what going pear shaped -- maybe ???
Thanks
Mark.
>
Message: 5
>
Date: Wed, 9 Jun 2004 20:13:37 -0700
>
To: email@hidden
>
From: Dakidd <email@hidden>
>
Subject: Proper usage of OTAsyncOpenEndpointInContext()
>
>
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
------ End of Forwarded Message
_______________________________________________
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.