erik@mpx1.UUCP (Erik Murrey) (10/02/88)
How can I do a portable nap()? A nap() (under XENIX) allows
a user process to block for a short time, usually a few hundred ms.
In any case, SysVr2 doesn't support a nap()-like call which is
very useful for two reasons (that I can think of):
1.
Communications protocols implemented at the user process
level (e.g. uucico, etc.)
2.
Character input routines that must distinguish between
ESC and a function key.
I hear that some systems have a special device for nap()-ing, and
others use select(), and still others are stuck with using a
CPU intensive while() loop using the times() call.
Does SysVr3 address this? How about SysVr4?
If this has already been hammered to death, then please e-mail
me a summary.
Thanks!
Erik Murrey
--
Erik Murrey /| // /~~~~/ | /
MPX Data Systems, Inc. / | / / /____/ |/
erik@mpx1.UUCP / / / / /| Data Systems, Inc.
{spl1,vu-vlsi,bpa}!mpx1!erik / / / / |====================debra@alice.UUCP (Paul De Bra) (10/03/88)
In article <543@mpx1.UUCP> erik@mpx1.UUCP (Erik Murrey) writes: >How can I do a portable nap()? A nap() (under XENIX) allows >a user process to block for a short time, usually a few hundred ms. > >In any case, SysVr2 doesn't support a nap()-like call which is >very useful for two reasons (that I can think of): > I opened my Unix V9 manual, and yes of course, nap(2) is there. So if you wait a few years until the System-V people pick up this idea from research (took a while with streams too as I recall) nap() will become portable. |-------------------------------------------------------------------------- |Paul De Bra | I am completely surrounded by giant bugs ! | |debra@research.att.com | There's millions of them, all over this code! | |uunet!research!debra | Beam me up quickly...Please... | |--------------------------------------------------------------------------
hiebeler@rpics (Dave Hiebeler) (10/03/88)
In article <543@mpx1.UUCP> erik@mpx1.UUCP (Erik Murrey) writes: >How can I do a portable nap()? A nap() (under XENIX) allows >a user process to block for a short time, usually a few hundred ms. >... >I hear that some systems have a special device for nap()-ing, and >others use select(), and still others are stuck with using a >CPU intensive while() loop using the times() call. I'm not sure if this is what you're asking, but in SunOS 3.x and later, there's a routine called usleep() which sleeps for the specified number of microseconds. I don't know if this routine exists in other Unix variations (though I don't believe it exists in Sequent's Dynix, when I was looking for it about a year ago). Hope that helps.. ---- Dave Hiebeler Internet: hiebeler@cs.rpi.edu (preferred address) R.D. Box 225A userfrzk%mts@itsgw.rpi.edu Chatham, NY 12037 Bitnet: userfrzk@rpitsmts.bitnet "xue zai xao"
nick@ccicpg.UUCP (Nick Crossley) (10/03/88)
In article <543@mpx1.UUCP> erik@mpx1.UUCP (Erik Murrey) writes: >How can I do a portable nap()? A nap() (under XENIX) allows >a user process to block for a short time, usually a few hundred ms. >How about SysVr4? >Erik Murrey >MPX Data Systems, Inc. According to the information given out at the SysVr4 Software Developer Conference, nap will be in V.4. -- <<< standard disclaimers >>> Nick Crossley, CCI, 9801 Muirlands, Irvine, CA 92718-2521, USA Tel. (714) 458-7282, uucp: ...!uunet!ccicpg!nick
henry@utzoo.uucp (Henry Spencer) (10/04/88)
In article <27909@ccicpg.UUCP> nick@ccicpg.UUCP (Nick Crossley) writes: >According to the information given out at the SysVr4 Software Developer >Conference, nap will be in V.4. *Everything* will be in V.4. :-( -- The meek can have the Earth; | Henry Spencer at U of Toronto Zoology the rest of us have other plans.|uunet!attcan!utzoo!henry henry@zoo.toronto.edu
herder@myab.se (Jan Herder) (10/04/88)
In article <543@mpx1.UUCP> erik@mpx1.UUCP (Erik Murrey) writes: >How can I do a portable nap()? A nap() (under XENIX) allows >a user process to block for a short time, usually a few hundred ms. >Does SysVr3 address this? How about SysVr4? Since SysVr3.2 is a merge between XENIX and SysVr3 nap() should be there. Another way under SysV is to do a read with timeout one a tty. -- Jan Herder, MYAB Sweden | Phone: +46 31 18 75 12 Internet: herder@myab.se | Fax: +46 31 18 28 42 UUCP: uunet!enea!chalmers!myab!herder | Address: Dr. Forseliusg 21 ARPA: herder%myab.se@uunet.uu.net | 413 26 Gothenburg
dave@lsuc.uucp (David Sherman) (10/05/88)
In article <8258@alice.UUCP> debra@alice.UUCP (Paul De Bra) writes: >In article <543@mpx1.UUCP> erik@mpx1.UUCP (Erik Murrey) writes: >>How can I do a portable nap()? A nap() (under XENIX) allows >>a user process to block for a short time, usually a few hundred ms. >> >I opened my Unix V9 manual, and yes of course, nap(2) is there. >So if you wait a few years until the System-V people pick up this >idea from research (took a while with streams too as I recall) >nap() will become portable. If you can't wait that long and you have source (or perhaps even if you have just enough source to be able to add your own drivers), here's the device driver nap.c. You stick this in your kernel with the right hooks (mail me if you can't figure out the hooks), mknod /dev/nap, and then compile the second nap.c, which nap.o gets ar'ed into /lib/libc.a (i.e., installed as a library function nap(3)). The trick is that a call to nap() is really an ioctl to a device that does the nap. You use up a file descriptor, but otherwise it's a pretty nice and clean way to implement it. ===================== nap.c, from /usr/sys/dev ============== /* nap - nap for hundredths of seconds. By garfield!sean, * installed by Dave Sherman October/84, from PDP-11/23 version */ #include "sys/nap.h" #if NNAP > 0 #include "sys/param.h" #include "sys/systm.h" #include "sys/tty.h" #include "sys/dir.h" #include "sys/user.h" #include "sys/proc.h" #define N_NAP 32 #define NAPPRI 31 int ttnap[N_NAP]; napioctl(dev, cmd, addr, flags) dev_t dev; caddr_t addr; { int wakeup(); int *ptr; for(ptr=ttnap; *ptr && (ptr <= &ttnap[N_NAP]); ptr++); if(ptr == &ttnap[N_NAP]) { u.u_error = ENXIO; return; } *ptr = u.u_procp->p_pid; timeout(wakeup, ptr, cmd); sleep(ptr, NAPPRI); *ptr = 0; } napclose(dev, flags) dev_t dev; { int *ptr; for(ptr=ttnap; (*ptr != u.u_procp->p_pid) && (ptr <= &ttnap[N_NAP]); ptr++); if(*ptr == u.u_procp->p_pid) *ptr = 0; } #endif ==================== nap.c, from /usr/src/libc/local ======== /* * nap - uses ioctl as set up by garfield!sean * * Dave Sherman, June 1983 */ nap(hundredths) register hundredths; { static napfd = -1; if(napfd < 0) { napfd = open("/dev/nap", 0); if(napfd < 0) return(-1); } ioctl(napfd, hundredths, 0); } ====================================================== The above code is for a v7 system; the details may vary slightly for other versions of UNIX. Also, the "hundredths" may be sixtieths (of a second) on many systems. Thanks to Sean Byrne, once garfield!sean, then philabs!scb, where are you now?, for the original device driver code. Please send me mail if you find this useful. David Sherman The Law Society of Upper Canada Toronto -- { uunet!attcan att pyramid!utai utzoo } !lsuc!dave
jfh@rpp386.Dallas.TX.US (The Beach Bum) (10/05/88)
In article <1988Oct3.230916.995@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes: >In article <27909@ccicpg.UUCP> nick@ccicpg.UUCP (Nick Crossley) writes: >>According to the information given out at the SysVr4 Software Developer >>Conference, nap will be in V.4. > >*Everything* will be in V.4. :-( You are all hereby directed to read my old System V flames and the discussions I've had on the net with Guy Harris. System V is a pig and should be put on a diet. Me? I'm still holding out for Version 7 on a 386 ;-) -- John F. Haugh II (jfh@rpp386.Dallas.TX.US) HASA, "S" Division "Why waste negative entropy on comments, when you could use the same entropy to create bugs instead?" -- Steve Elias
scott@dtscp1.UUCP (Scott Barman) (10/07/88)
In article <7548@rpp386.Dallas.TX.US> jfh@rpp386.Dallas.TX.US (The Beach Bum) writes: >In article <1988Oct3.230916.995@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes: >>*Everything* will be in V.4. :-( > >Me? I'm still holding out for Version 7 on a 386 ;-) I'm holding out for the improbable release of Version 9! Maybe if enough of us ask AT&T nicely they'd (1) do it and (2) get the message that System V stinks!!!! So much for sane Unix! :-) -- scott barman ..!gatech!dtscp1!scott
gwyn@smoke.ARPA (Doug Gwyn ) (10/07/88)
In article <385@dtscp1.UUCP> scott@dtscp1.UUCP (Scott Barman) writes: >I'm holding out for the improbable release of Version 9! If you'd be able to cope with it, you be able to get it, but as was noted in Dennis's private letter that got posted by mistake, it needs TLC and therefore is probably too much hassle for most sites. Many of 9th Edition UNIX's nicest features are gradually appearing in the System V product anyway.
ed@mtxinu.UUCP (Ed Gould) (10/08/88)
>I'm holding out for the improbable release of Version 9! >Maybe if enough of us ask AT&T nicely they'd (1) do it and (2) get the >message that System V stinks!!!! It might be plausible to consider asking AT&T to release the 9th Edition commercially if one could convince *all* of their licensees (including DEC, IBM, and a few other companies) to in turn convince *all* of their customers that this is the right thing to do. What AT&T really doesn't want is to support more than one version of Unix themselves (independant of the fact that they'd rather the other variants all went away). What would this take? My estimate is a few tens of billions of dollars. -- Ed Gould mt Xinu, 2560 Ninth St., Berkeley, CA 94710 USA {ucbvax,uunet}!mtxinu!ed +1 415 644 0146 "I'll fight them as a woman, not a lady. I'll fight them as an engineer."
allbery@ncoast.UUCP (Brandon S. Allbery) (10/09/88)
As quoted from <543@mpx1.UUCP> by erik@mpx1.UUCP (Erik Murrey): +--------------- | In any case, SysVr2 doesn't support a nap()-like call which is | very useful for two reasons (that I can think of): | | 1. Communications protocols implemented at the user process | level (e.g. uucico, etc.) | 2. Character input routines that must distinguish between | ESC and a function key. +--------------- May I suggest that for both of these, VMIN and VTIME in the tty driver are what you should look for? Input routines: int baudrate[] = { 50, 75, 110, 134, 150, 200, 300, 600, 1200, 1800, 2400, 4800, 9600, 19200, /* EXTA: change as appropriate */ 38400, /* EXTB: change as appropriate */ }; baud_based_timeout(speed, maxlen) { int timeout; /* * 100 below is actually bits_per_char * 10 (for tenths * of a second). bits_per_char is calculated as the * data bits + parity bit + stop bits + start bit, and is * typically 10 (7 + 1 + 1 + 1 or 8 + 0 + 1 + 1). */ timeout = maxlen * 100 / baudrate[speed]; } tty.c_lflags &= ~ICANON; tty.c_cc[VMIN] = strlen(longest_fkey); tty.c_cc[VTIME] = baud_based_timeout(tty.c_cflags & CBAUD, tty.c_cc[VMIN]); ioctl(0, TCSETAW, &tty); ... keylen = read(0, &keybuf, tty.c_cc[VMIN]); if (keylen > 1) { /* function key */ ... } else { /* regular key, including ESC */ ... } For communications protocols, set VMIN to the size of the longest packet (in case it's not obvious: "VMIN" should probably have been called VMAX as far as its actual usefulness, although there is a rationale for its name) and VTIME to baud_based_timeout(speed, max_packet_len) [baud_based_timeout() as above]). Use as above; the timeout catches short packets, the VMIN prevents the start of the next packet from being read as part of the current packet. Then check the packet header to see what you got, in conjunction with the returned length. Some people will have noticed that I refer to -icanon mode as "packet mode" -- this is why. [This has not been discussed before, as far as I know, and it *is* a useful feature of System V.] ++Brandon -- Brandon S Allbery uunet!hal.cwru.edu!ncoast!allbery allbery%ncoast@hal.cwru.edu (LAST RESORT ONLY: allbery@uunet.uu.net) DELPHI: ALLBERY comp.sources.misc is moving off ncoast -- please do NOT send submissions direct "So many articles, so little time...." -- The Line-Eater
robert@pvab.UUCP (Robert Claeson) (10/10/88)
In article <27909@ccicpg.UUCP>, nick@ccicpg.UUCP (Nick Crossley) writes: > In article <543@mpx1.UUCP> erik@mpx1.UUCP (Erik Murrey) writes: > >How can I do a portable nap()? A nap() (under XENIX) allows > >a user process to block for a short time, usually a few hundred ms. > According to the information given out at the SysVr4 Software Developer > Conference, nap will be in V.4. And since SVR3.2 is supposed to include most (all?) of Xenix, nap() should be in it, too. -- Robert Claeson, ERBE DATA AB, P.O. Box 77, S-175 22 Jarfalla, Sweden Tel: +46 758-202 50 Fax: +46 758-197 20 Email: robert@pvab.se (soon rclaeson@erbe.se)
erik@mpx1.UUCP (Erik Murrey) (10/10/88)
In article <12665@ncoast.UUCP>, allbery@ncoast.UUCP (Brandon S. Allbery) writes: > May I suggest that for both of these, VMIN and VTIME in the tty driver are > what you should look for? > > [example deleted] This might work reliably at 1200 or 2400 baud, but what happens above that? Termio() only allows time values in 1/10 second increments. Isn't there a good chance that more than one keystroke will be received within 1/10th of a second? At 9600 baud, or 19.2k? This is why nap() works so well. It has a HZ resultion, which is 1/50 of a second on my AT clone, even higher on bigger machines... -- Erik Murrey /| // /~~~~/ | / MPX Data Systems, Inc. / | / / /____/ |/ erik@mpx1.UUCP / / / / /| Data Systems, Inc. {spl1,vu-vlsi,bpa}!mpx1!erik / / / / |====================
scott@dtscp1.UUCP (Scott Barman) (10/11/88)
In article <8654@smoke.ARPA> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes: |In article <385@dtscp1.UUCP> scott@dtscp1.UUCP (Scott Barman) writes: |>I'm holding out for the improbable release of Version 9! | |If you'd be able to cope with it, you be able to get it, |but as was noted in Dennis's private letter that got posted |by mistake, it needs TLC and therefore is probably too much |hassle for most sites. Many of 9th Edition UNIX's nicest |features are gradually appearing in the System V product |anyway. I might be more willing to deal with whatever v9 problems are than the garbage and gunk I've been through dealing with SVr3 on the box I am on now! -- scott barman ..!gatech!dtscp1!scott
sjs@jcricket.ctt.bellcore.com (Stan Switzer) (10/11/88)
In article <1988Oct3.230916.995@utzoo.uucp> Henry Spencer writes: > In article <27909@ccicpg.UUCP> nick@ccicpg.UUCP (Nick Crossley) writes: > >According to the information given out at the SysVr4 Software Developer > >Conference, nap will be in V.4. > > *Everything* will be in V.4. :-( > -- > The meek can have the Earth; | Henry Spencer at U of Toronto Zoology > the rest of us have other plans.|uunet!attcan!utzoo!henry henry@zoo.toronto.edu Well, there you go again.... Nap costs absolutely nothing to provide and provides a useful function which cannot be performed in any other way in Sys V.3. Or is this just another opportunity to bash V.4? :-( :-( -- The wreckless can exploit space; Let the more | Stan Switzer temperate among us preserve our precious Earth. | sjs@ctt.bellcore.com
henry@utzoo.uucp (Henry Spencer) (10/14/88)
In article <10852@bellcore.bellcore.com> sjs@ctt.bellcore.com (Stan Switzer) writes: >Nap costs absolutely nothing to provide and provides a useful function >which cannot be performed in any other way in Sys V.3. Sorry, the cost is not zero, not in the real world. Especially when AT&T is doing it. However, I personally don't have it in for nap, particularly; I just dislike the V.4 policy of "if you ever wanted it, or even if you didn't, no matter what it is or how stupid it is, it's in V.4". -- The meek can have the Earth; | Henry Spencer at U of Toronto Zoology the rest of us have other plans.|uunet!attcan!utzoo!henry henry@zoo.toronto.edu
sjs@jcricket.ctt.bellcore.com (Stan Switzer) (10/14/88)
In article <1988Oct13.233045.18101@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes: > In article <10852@bellcore.bellcore.com> > sjs@ctt.bellcore.com (Stan Switzer) writes: > >Nap costs absolutely nothing to provide and provides a useful function > >which cannot be performed in any other way in Sys V.3. > > Sorry, the cost is not zero, not in the real world. Especially when AT&T > is doing it. However, I personally don't have it in for nap, particularly; > I just dislike the V.4 policy of "if you ever wanted it, or even if you > didn't, no matter what it is or how stupid it is, it's in V.4". I'll concede that the cost is (somewhat greater than zero), and also that overinclusiveness (non-orthogonality especially) at the system call level is a sure sign of a bloated design, but I think you'll have to agree that they're trying to solve a hard problem and that it could have been worse. Ideally, they could have made some "tough" choices (anyone else getting tired of that word?) BUT... Brain-damage is in the eyes of the beholder (to mangle a phrase). The BSD partisans, and with considerable justification, got pretty cocky what with their sockets and their select and their wait3 and their "more" etc, versus AT&T's System V.2 which for the looooongest time just stood still. Now, reasonable people can disagree whether V.3 represents a true improvement over BSD, but at least it finally established some amount of parity between the two worlds. Unfortunately, we are left with (frequently gratuitous) differences, and with large quantities of code which has been built to one system or another. Today, with hindsight, anyone could design a system that is better than either BSD or SysV, but this isn't really the point. The point is who'd buy a system with still more gratuitous incompatibilities? So, we have here a classic engineering problem (engineering: applied compromise). The task at hand is a bridge from point "A" to point "B." Yeah, I want the bridge to be pretty too -- sleek lines, no gaudy ornamentation and gee-gaws -- but in the real world, this will be a secondary concern. It is pretty clear that this has become the "Reagan era of computing" where everyone wants to consolidate on one programming language, one operating system, one true system of computing. The UNIX community is now facing a totally new reality. UNIX is no longer the small furry mammal taunting the slow lumbering dinosaurs. UNIX is now the status quo! Has UNIX been discovered, or has it been found out? Can UNIX (without substantial reworking) ever aspire to be more than a time sharing system? We live in interesting times indeed! There are only two alternatives for the immediate future: Find a reasonable (if not entirely beautiful) way to consolidate upon the successes of BOTH BSD and Sys V (Oops! almost forgot POSIX and XJ311, and /usr/group, and OSF, and ...). Or, come up with something which represents a quantum leap forward from UNIX (and while you are at it, you better figure out how to be UNIX compatible too). As for the former, it seems that V.4 is about as good as it is going to get. For the latter, I'd suggest you take a look at Tanenbaum's Amoeba system work. Perhaps Amoeba is the shape of the future. Stan Switzer Not quite ready to give up on the Earth. sjs@ctt.bellcore.com
rhammon@lll-lcc.llnl.gov (Randall R. Hammon) (10/17/88)
Does anyone know whether adb can show you the interrupt stack pointer when you are looking at a crash dump? I can look at the interrupt stack by using the intstack symbol, but I need to know what part of the stack is currently active.( BTW, my money says that it can't ). Thanks, -Randy Hammon rhammon@lll-lcc.llnl.gov Lawrence Livermore Lab. (415)422-6881