Mailing Lists: Apple Mailing Lists
 Image of Mac OS face in stamp
Re: Asynchronous OTRcv & OTTimerTasks
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Asynchronous OTRcv & OTTimerTasks

on 3/22/01 11:37 AM, Tomas Zahradnicky, Jr. at email@hidden
wrote:

> i'm doing an application which reads data from serial port. in order
> to constantly load data from serial port to my buffer i decided to
> write it using asynchronous nonblocking serial endpoint. what happens
> if i get T_DATA event in notifier and i read less data or ignore
> T_MORE flag? will i get another T_DATA event later or I have to
> remember that thing and try to read data myself later (not from
> notifier).

You will need to remember it and receive on your own later, either in
the notifier or outside. Quinn wrote an email about this a while back, here
it is:

------------------------------------------------------------------
1. Binding for Outgoing Connections -- If you're making an outgoing
connection, call OTBind as shown below:

err = OTBind(ep, nil, nil);

Do not specifically look up the IP address of the local machine and
bind to that. Doing so will cause you problems in the future (eg
multi-homing, IPv6).

2. AF_DNS -- When making outgoing connections, try to use AF_DNS
where possible. There's no point in you resolving a DNS address and
then connecting to the IP address; OT will do it just as effectively.
Also, using AF_DNS will ease your path to IPv6.

3. Binding for Incoming Connections -- When listening for
connections, bind to the address kOTAnyInetAddress (zero). This way
you will receive notification when a connection occurs to *any* of
the machine's IP addresses.

Do not call OTInetGetInterfaceInfo and bind to the specific IP
address of the machine, unless you want to treat connections
differently depending on which IP address was connected to.

This warning is especially important for UDP, where binding to a
specific address will prevent you receiving broadcast packets.

4. Use "tilisten" -- When listening for incoming connections, use the
"tilisten" module to simplify the listen/accept handoff. See "Inside
Macintosh: Networking with Open Transport" for details:


<http://developer.apple.com/techpubs/mac/NetworkingOT/NetworkingWOT-32.html>

5. Send-Side Flow Control -- When sending data in async mode, the rules are:

1. Keep calling OTSnd (or OTSndUData) until either:
a) it returns kOTFlowErr, or
b) you run out of data.

2. If you get kOTFlowErr, you endpoint is "send-side flow controlled".
You should stop sending data until your notifier is called
with a T_GODATA event.

In some cases, OTSnd (and OTSndUData) will return a
kOTOutOfMemoryErr. If this happens, your best recourse is to delay
for some period of time and then attempt the send again.

6. Receive-Side Flow Control -- When receiving data in async mode,
the rules are:

1. When you get a T_DATA event, keep calling OTRcv (or OTRcvUData)
until either:
a) you no longer have space to receive any more data, or
b) it returns kOTNoDataErr.

2. If you run out of buffer space, you must remember that your endpoint
is "read-side flow controlled". When you have consumed enough
data to free up some buffers, you must remember to call OTRcv
(or OTRcvUData) again.

The critical point here is that you won't get another T_DATA event
until you have read data to the point where OT returns kOTNoDataErr.

7. Dialing the Modem -- The modem dials when you create a TCP/IP
endpoint. To avoid annoying your user, follow the rules in:

<http://developer.apple.com/technotes/tn/tn1145.html>

8. Handle Endpoints Closing Underneath You -- In some cases, OT will
close an endpoint out from underneath you. To learn more about this,
see:

<http://developer.apple.com/technotes/tn/tn1145.html>
------------------------------------------------------------------

> second thing is: do i need to call OTEnterInterrupt & OTEnterNotifier
> from timer task & notifier? i think that they are used to prevent
> reentrancy (otenternotifier) and to tell OT that you're about to call
> some of its function like otrcv, right?

If I understand right, you need to call OTEnterInterrupt for anything
older than OS 9.1. But I would call it always, just to be sure that it
works in OS 8. Quinn talked about this when he was describing how to get a
kOTBadSyncErr:

--------------
The error you're getting, kOTBadSyncErr, is indicative of a
programming error. You should not get this error in correctly
designed code. There are two common ways the error can occur.

1. Synchronous operations at 'interrupt time'. If you try to do a
synchronous operation (typically an operation on an endpoint which
has been set to synchronous mode) at 'interrupt time' (any non-system
task time, such as the deferred task time that OT notifiers run in)
you will get this error.

2. Operations at 'hardware' interrupt time -- Most OT routines can
only be called legally from system task time or deferred task time.
Calling them from other interrupt times (such as a Time Manager task,
or a File Manager I/O completion) is illegal. If you do this, and OT
detects it, you will get this error.

In Mac OS 9.1 OT does a much better job of detecting when you call it
from an illegal context. Prior to Mac OS 9.1 OT could only detect
hardware interrupt time if you had religiously called
OTEnter/LeaveInterrupt as you enter and leave your interrupt
handlers. In Mac OS 9.1 on NewWorld machines OT can always detect
hardware interrupt time (OTEnter/LeaveInterrupt have becomes NOPs).

So, in summary, to get this error you're probably either a) doing an
operation on a synchronous endpoint from your notifiers, or b)
running your notifier at hardware interrupt time.
---------------

Hope this helps,

Zack Morris
Z Sculpt Entertainment
email@hidden
http://www.zsculpt.com

References: 
 >Asynchronous OTRcv & OTTimerTasks (From: "Tomas Zahradnicky, Jr." <email@hidden>)



Visit the Apple Store online or at retail locations.
1-800-MY-APPLE

Contact Apple | Terms of Use | Privacy Policy

Copyright © 2011 Apple Inc. All rights reserved.