Date: Wed, 10 Feb 1999 17:38:35 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: des@flood.ping.uio.no (Dag-Erling Smorgrav) Cc: dcs@newsguy.com, des@flood.ping.uio.no, dillon@apollo.backplane.com, kuku@gilberto.physik.RWTH-Aachen.DE, peter@netplex.com.au, tlambert@primenet.com, hackers@FreeBSD.ORG Subject: Re: portability of shm, mmap, pipes and socket IPC Message-ID: <199902101738.KAA14521@usr07.primenet.com> In-Reply-To: <xzpww1q9u9r.fsf@flood.ping.uio.no> from "Dag-Erling Smorgrav" at Feb 10, 99 04:02:24 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > > Matthew Dillon <dillon@apollo.backplane.com> writes: > > > > The problem is that linux updates the timeval structure on return, > > > > telling you how much time is left. Linux doesn't do this in the default implementation any more. They have a seperate system call that still does this. > > > Yup. I wish FreeBSD did that - the man page already states that one > > > shouldn't rely on tv not being modified, so it shouldn't break POLA. > > > > Manual pages aren't POLA. They are specs. Traditional usage is POLA. > > Wanna different different behavior? Create a different function. > > Yep, man pages are specs, and when the spec says tv may be modified by > select(), that means you can't expect it to remain untouched. When writing new code. > > Besides, given that most usages have no need for this, it would be a > > wast of space and time. > > 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. Actually, it's not that useful, unless you are somehow aware of the amount of time spent in processing in the case that the descriptors select true. I actually wrote an X game a while ago (a "LodeRunner" clone) that used the processing time information as part of the data. Basically, you have to set your timeout interval down to the amount of time that it takes to process in the case that the select comes true so that the "tick size" in both cases is the same, and then do things in terms of "ticks". Obviously, for smooth game play, the tick size varies based on the system you are running the code on, so a calibration loop is used to initialize it. In general, people bemoan the existance of timeout modification by the underlying code most often when they bring System V expectations into their use of th BSD select(2) call; expectations like "signals will interrupt instead of restarting system calls by default", etc.. In this particular case, a restart is supposed to start it where it left off, not from ground zero (SunOS 4.1.3 will do this, like most BSD4.3 based systems, but most BSD4.4 based systems won't). You can combine this with interval timers (or the badly documented HRT on SVR4) to get very good granularity. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. 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?199902101738.KAA14521>