Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!swrinde!elroy.jpl.nasa.gov!decwrl!sgi!shinobu!odin!hwajin
From: hwajin@sgi.com (Hwa-jin Bae)
Newsgroups: comp.realtime
Subject: Re: VxWorks task scheduling
Message-ID: <1991Mar30.005837.3296@odin.corp.sgi.com>
Date: 30 Mar 91 00:58:37 GMT
References: <907@adaptive.UUCP>
Sender: news@odin.corp.sgi.com (Net News)
Reply-To: hwajin@pei.com
Distribution: usa
Organization: Silicon Graphics, Inc., Mountain View, CA.
Lines: 24
In-Reply-To: casey@asi.com's message of 29 Mar 91 01:24:18 GMT

>>>>> On 29 Mar 91 01:24:18 GMT, casey@asi.com (Casey Bahr) said:

Casey> Now with 5.0 most of the tasks seem to get scheduled fine, except
Casey> one, which seems to get locked out (waiting at a socket accept() call).

When a task is "locked out" waiting at a socket accept() call, it is
basically pending on a semaphore (pending on a semTake()), which will
not return until the semaphore you're pending on is available.  This
is the proper behavior.  In most cases, this is also desired behavior
since you want this task to pend until a connection is accepted.  If
your application doesn't want to pend forever on a semaphore waiting
for a new connection, you should use select(), which takes a timeout
value.  Upon return from select() you can check if there's anything
interesting going on on the socket.  You can then choose to accept()
or do something else.

*hwajin



--
Hwa Jin Bae	hwajin@{pei.com, wrs.com, igc.org, unisoft.com}
Protocol Engines, Inc.		
Mountain View, CA