On Thursday 18 August 2011 00:31, Rich Felker wrote: > On Thu, Aug 18, 2011 at 12:16:30AM +0200, Denys Vlasenko wrote: > > On Wednesday 17 August 2011 23:20, Rich Felker wrote: > > > I hate it when fools who don't know what they're doing and don't > > > respect standards lobby for nonstandard behavior in Linux, thereby > > > making the portability landscape *worse* than it already it. Instead > > > try to understand why things are the way they are and just stop > > > insisting on doing stupid things (like setting nonblocking mode on a > > > fd you inherited). > > > > I already asked this question and you ignored it. > > So here it is again: > > > > How can I do nonblocking read from fd 0 without > > affecting other processes which might share it? > > Assuming no other process will be reading at the same time,
No, I meant "how to do it the most general case". Including the case when someone else reads concurrently. > you simply > call poll first (or select, but select requires the fd # to be < 1024) > to check that it won't block, then call read. select and poll are > specified to only mark the fd readable if a read would not block. An example from a different area of Unix API: EINTR is supposed to be returned only if non-DFL, non-IGN signal was reseived and handler was executed. Right? Right... but... real world chimes in: EINTR also may be returned if someone happened to attach to your program with "strace -p PID" while you are in a syscall. Syscall may return EINTR even though *no signal whatsoever* was delivered. Isn't it great when you try to debug a program with strace and a hiccup like this makes it change behaviour just because program author did not bother to check EINTR "because it can't happen here"? IOW: real world tends to be nasty. Defensive programming is a good strategy. Using non-blocking I/O after poll/select is one of those cases. My question stands: "How can I do nonblocking read from fd 0 without affecting other processes which might share it?" I don't need a lecture how I should use select/poll, or that I shall not use nonblocking reads, or that shared reads from shared fds are stupid. I ask you how to perform nonblocking reads safely. Because from where I sit, current Unix API doesn't provide for 100% safe (wrt races) way to do it. IOW: I want recv(fd, buf, len, MSG_DONTWAIT) equivalnet which would work on any kind of fd, not only on socket fds. Does it exist? Yes or no? If no, why socket read op has this nice, non-racy nonblocking read and ordinary read op doesn't? Isn't it a hole in API? > If other processes might attempt a read at the same time your process > does, then you have serious data races which are probably not solvable > anyway. Well, the data units might be single bytes. > It's extremely rare that you would have a valid situation > where you need to do this; I sure can't think of any. Again, answering something other than my question. Not interested. -- vda _______________________________________________ busybox mailing list [email protected] http://lists.busybox.net/mailman/listinfo/busybox
