Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 18 Feb 1999 02:51:07 -0500 (EST)
From:      Alfred Perlstein <bright@cygnus.rush.net>
To:        Warner Losh <imp@village.org>
Cc:        Dag-Erling Smorgrav <des@flood.ping.uio.no>, "Daniel C. Sobral" <dcs@newsguy.com>, Matthew Dillon <dillon@apollo.backplane.com>, Christoph Kukulies <kuku@gilberto.physik.RWTH-Aachen.DE>, Peter Wemm <peter@netplex.com.au>, Terry Lambert <tlambert@primenet.com>, hackers@FreeBSD.ORG
Subject:   Re: portability of shm, mmap, pipes and socket IPC 
Message-ID:  <Pine.BSF.3.96.990218024628.10060G-100000@cygnus.rush.net>
In-Reply-To: <199902180442.VAA64894@harmony.village.org>

next in thread | previous in thread | raw e-mail | index | archive | help


On Wed, 17 Feb 1999, Warner Losh wrote:

> That's in the bugs section:
>      select() should probably return the time remaining from the original
>      timeout, if any, by modifying the time value in place.  This may be im-
>      plemented in future versions of the system.  Thus, it is unwise to assume
>      that the timeout value will be unmodified by the select() call.
> 
> Notice "should" and "may be"  It doesn't say "Will" or "does".
> 
> : On the contrary, it is extremely useful for implementing higher-level
> : timeouts. If you want to see the new installer come true, I need to
> : implement protocol-level timeouts in libfetch, and that means either
> : add a lot of gettimeofday() logic or fix select() to modify tv.
> 
> Even if that represents an unavoidable race condition?

Why has no one considered the idea of 'select2()' which would finally
--------------------------------------------^^^
implement the argument modification?  This would finally dispell confusion
about what will do what, when where and why etc.. if properly documented
of course.

simple: 

select == non modifying behavior
select2 == modifies

Thisleaves legacy/dumb code alone and at the same time gives more
functionality to applications that know how to use the interface...

-Alfred

> 
> Warner
> 
> 
> To Unsubscribe: send mail to majordomo@FreeBSD.org
> with "unsubscribe freebsd-hackers" in the body of the message
> 



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.96.990218024628.10060G-100000>