Date: Wed, 23 Jul 1997 00:12:36 -0700 (PDT) From: FreeBSD Technical Reader <kernel@acromail.ml.org> To: Josh MacDonald <jmacd@CS.Berkeley.EDU> Cc: Paul Traina <pst@shockwave.com>, hackers@FreeBSD.ORG Subject: Re: how to tell if getchar() will block -- select doesn't cut it Message-ID: <Pine.BSF.3.96.970723000714.26149A-100000@acromail.ml.org> In-Reply-To: <199707230637.XAA20188@paris.CS.Berkeley.EDU>
next in thread | previous in thread | raw e-mail | index | archive | help
Your right about this what I tend to do in this case is nonblocking of file descriptors when opening them thn using fdopen to attach a file pointer to them then i use stdio library only for output (i.e. printf for output and read for input, this gets around the lameness with stdio buffering input especially for interacive stuff where your reading from serial devices becuase you don't want input line buffered but you can use fflush to flush outputs (i don't know of there being a way to force stdio functions i.e. getchar to see everything that has come in on those devices). On Tue, 22 Jul 1997, Josh MacDonald wrote: > It's a bad idea to try and use the stdio library while trying to be > select() aware in the first place. It's a bad practice to make non- > blocking reads when you don't think anything is available because > you'll end up spinning with no input available. Then your line editor > chews CPU while idle. If I were you I would write the 30 or 40 lines of > code that replace stdio's getchar with whatever you need for user input > that is integrated with your select event loop. > > -josh > > > Yeah, I had thought of that, however, that means that the whole code-loop > > is forced to become non-blocking aware. I use that technique in some > > other places in related code. > > > > Thanks for the idea though, > > > > Paul > > >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.96.970723000714.26149A-100000>