Re: [Repost] OTCountFreeBytes? (like OTCountDataBytes but for send)
Re: [Repost] OTCountFreeBytes? (like OTCountDataBytes but for send)
- Subject: Re: [Repost] OTCountFreeBytes? (like OTCountDataBytes but for send)
- From: Quinn <email@hidden>
- Date: Fri, 1 Feb 2002 09:53:26 +0000
At 5:08 +0300 1/2/02, Mike Kluev wrote:
:-( I presume, that OT is "stable" enough (contrary to e.g. Carbon)
to make such a feature request.
Do you mean you'd like to request this as a new feature in the OT
API? If so, your chances of getting it are "slim to none". Mac OS X
is now the default OS on all our systems, and Mac OS 9 development is
limited to new hardware support and critical bug fixes. On Mac OS X
the OT compatibility library is just that, a compatibility library.
It's unlikely we'd be adding convenience features to it, especially
if those features aren't already in Mac OS 9. Our long term goal is
for developers to use the OT API only if they need to support both 9
and X, and to use one of X's many alternative networking APIs if they
have an X-only product.
Thanks for the reference.
btw Do you need this to work on Mac OS X's OT compatibility shim, or
just real OT? If the former, I wouldn't even bother opening a TSI.
>...
What do you mean? I want it to run on Mac OS 9 and Mac OS X native;
which is "real OT"? Isn't OT real under Mac OS X?
Mac OS X does not have "real OT" (unless you count inside Classic),
it has an OT compatibilty library that shims through to the BSD
sockets API, which in turn is supported directly by the kernel. All
of the OT infrastructure (STREAMS) is not present on Mac OS X.
So, my comment should have read "Don't bother opening a TSI if your
program runs on Mac OS X using its OT compatibility library. All the
scary workarounds I can think of would utilitise STREAMS-specific
features that won't be support on Mac OS X's OT compatibility
library."
Quinn, do you have answers for 5, 8 and 9, (see below).
Could it happen, under what circumstances, how often (for 5),
and how to treat it (for 8 and 9)).
I'll take a look...
>> 5. If kOTOutOfMemoryErr, remember what to send and prime timer
proc to send later. return done to caller.
(BTW, how often is this situation? Could I presume
that its probability is close to zero and just treat
>> as as rare fatal error?)
No. This happens often enough that you have to test for and recover
from it. The last time I looked at this was during the development
of OTMP. You might take a look at OTMP for some recovery hints.
<
http://developer.apple.com/samplecode/Sample_Code/Networking/OTMP.htm>
>> 8. If result = 0
(BTW, could it ever happen? If bytes sent <> 0?
>> If bytes sent = 0?) treat it as (3) (or 2?)
Treat it as 3).
>> 9. If result > bytes sent (BTW, could it ever happen?)
treat it as (3) (or 7?)
This should never happen. On the debug build I would "assert" that
it doesn't. On the production build I would shut down the stream and
spit up an annoying error dialog if it does.
S+E
--
Quinn "The Eskimo!" <
http://www.apple.com/developer/>
Apple Developer Technical Support * Networking, Communications, Hardware