From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,97ae587931c0f702 X-Google-Attributes: gid103376,public From: geert@fozzie.sun3.iaf.nl (Geert Bosch) Subject: Re: Ada Task priorities Date: 1997/01/27 Message-ID: <5chu9v$kll@fozzie.sun3.iaf.nl>#1/1 X-Deja-AN: 212538749 references: organization: La Calandre Infortunee newsgroups: comp.lang.ada Date: 1997-01-27T00:00:00+00:00 List-Id: Jonathan Polley (polley@netins.net) wrote: I have found that (with the Rational compiler at least) if a higher priority task is waiting on an OS event (i.e., waiting on data from a TCP socket), it will starve all lower priority tasks. Because of this, I make sure that all my I/O tasks (for TCP, UDP, and X) are the lowest priority tasks in the system. This is really bad behaviour! You want the call for waiting on data from a socket to be a blocking call, so it doesn't consume any CPU time at all. Setting the I/O tasks to high priority is very desirable, because then as soon as an I/O task is unblocked it will get the CPU to read the port and for example store it in a buffer for later processing. This way response to external events is very quick, which is desirable for interactive use such as X Windows. Since I/O tasks typically require the CPU only for very short periods of time before coming blocked again, setting these tasks to high priority shouldn't have adverse effects on the rest of the system. The way you are implementing I/O now makes it impossible to interact with the system while the CPU is used by calculations etc. This looks like unwanted behavior to me. Regards, Geert -- E-Mail: geert@sun3.iaf.nl ``I think there is a world market for maybe five computers.'' Thomas Watson, chairman of IBM, 1943