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: Mike Kluev <email@hidden>
- Date: Fri, 01 Feb 2002 05:08:46 +0300
On 1/2/02 1:58, Quinn <email@hidden> wrote:
>
At 20:41 +0300 31/1/02, Mike Kluev wrote:
>
> I need to determine how much could I send with OTSnd without
>
> blocking and without getting back "partial success" error or
>
> flow-control error.
>
...
>
Thus, my guess is that there's no way to do what you want.
:-( I presume, that OT is "stable" enough (contrary to e.g. Carbon)
to make such a feature request.
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?
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)).
>
> // Async blocking case
>
> DoSend():
>
>
>
> 1. Try to send (result = OTSnd).
>
>
>
> 2. If success (i.e. result == bytes sent) - done.
>
>
>
> 3. If partial success (i.e. result < bytes sent) goto (1)
>
>
>
> 4. If flow-control error, remember what to send, return
>
> done to caller. 'T_GODATA' event will eventually happen.
>
>
>
> 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?)
>
>
>
> 6. If look error - call OTLook and report to caller
>
>
>
> 7. If other error - report to caller.
>
>
>
> 8. If result = 0
>
> (BTW, could it ever happen? If bytes sent <> 0?
>
> If bytes sent = 0?) treat it as (3) (or 2?)
>
>
>
> 9. If result > bytes sent (BTW, could it ever happen?)
>
> treat it as (3) (or 7?)
Regards,
Mike Kluev