Re: Proper usage of OTAsyncOpenEndpointInContext()
Re: Proper usage of OTAsyncOpenEndpointInContext()
- Subject: Re: Proper usage of OTAsyncOpenEndpointInContext()
- From: Zack Morris <email@hidden>
- Date: Wed, 09 Jun 2004 23:32:20 -0600
On Jun 9, 2004, at 9:13 PM, Dakidd wrote:
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)
OEICResult =
OTAsyncOpenEndpointInContext(OTCreateConfiguration(kTCPName),
MyOpenFlags,
&ThePeer->EndpointInfo,
MyNotifierUPP,
(void *)ThePeer,
Globals.OTContext);
I think you can just open the endpoint synchronously and then call
OTSetAsynchronous() with no speed hit since you haven't reached out the
net yet (just don't do it during an interrupt since it's synchronous).
It seems like there was a question about that eons ago, and it was a
way to skip getting notified of some of the setup events, can't
remember. If that works, you can open a bunch of endpoints at startup
and keep them waiting in an OTLIFO until you need them, then pop them
off in your notifier. If you run out, just create more at system task
time and add them to the OTLIFO. If this sounds like gobbledegook, you
might want to research OTLIFOs and atomic operations before diving too
far into asynch networking. The learning curve is anywhere from a few
weeks to a few years and I am just now recovering. For instance, you
might want to put all the peers in an OTLIFO by putting an OTLink at
the front of the struct, so you don't have to worry about corrupting
the list in an interrupt. OT has come a long way and the code is
shorter now so that you don't have to include workarounds for old bugs.
Just make sure to require 9.1 so you don't have to deal with them
(take a look at the OTVirtualServer to get examples of old pitfalls).
This is offtopic, but, I just thought I'd let you know that I pretty
much finished a fancy asynch client/server about the time OS X came
out. I abandoned it in favor of nonblocking sockets, and then wrote a
sockets wrapper for 9, since I was using very few functions. You might
want to check out GUSI, the Codewarrior sockets lib, or just roll your
own sockets wrapper in OpenTransport if you only use like 10 functions.
This is perhaps better advice for someone working on OS X though.
There is also the OTMP stuff on 9 which I have never tried, but might
be infinitely easier than messing with asynch, since you can leave your
program structure essentially unchanged but put the networking in a
thread. I have never really heard of anyone using asynch in the real
world except for Interarchy. Please rate me -1 Troll now :)
P.S. if this doesn't work at all, just try a minimal
OTAsyncOpenEndpointInContext() at the top of your code, and if it
works, move it down until it crashes. Perhaps I am stating the
obvious, sorry :)
------------------------------------------------------------------------
----
Zack Morris Z Sculpt Entertainment This
Space
email@hidden
http://www.zsculpt.com For
Rent
------------------------------------------------------------------------
----
If the doors of perception were cleansed, everything would appear to
man as
it is, infinite. -William Blake, The Marriage of Heaven and Hell
_______________________________________________
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.