Date: Thu, 03 Apr 2003 13:53:22 -0800 From: Terry Lambert <tlambert2@mindspring.com> To: Igor Sysoev <is@rambler-co.ru> Cc: freebsd-arch@freebsd.org Subject: Re: libthr and 1:1 threading. Message-ID: <3E8CAD52.531E0A9@mindspring.com> References: <Pine.BSF.4.21.0304031849310.32175-100000@is>
next in thread | previous in thread | raw e-mail | index | archive | help
Igor Sysoev wrote: > > Now try redirecting input from a file. O_NONBLOCK is a flag; the > > system doesn't care if you are setting it on a file, a tty, the > > parallel port, or the PTY master; it's just a flag. > > And what do you suppose to see in this case ? You don't get an error, attempting to set the flag. When you read the flags, O_NONBLOCK will still be there. > When /kernel/genunix was not cached a read() takes 5157 usec's. > And no EAGAIN error. The point is not that you are not getting the error: we all know that you will *NOT* get the error, because the code does not support non-blocking operations returning EAGAIN in this context. The point is that the flag is not explicitly repudiated by the OS when you attempt to set it on disk files: you do not get an error from the OS when attempting to set the flag. > > Matt's first argument is that the flag has no effect on disk files > > in FreeBSD; I don't dispute that, and never did. > > Not only in FreeBSD. Linux and Solaris do the same. Solaris used to, when it was more SVR4, before Sun forked the code. SVR4 does. I don't care about what Linux does; if they miss an optimization, it's no skin off my nose. This whole thread is a thinly veiled attempt to say that FreeBSD should be more like Linux: it should adopt Linux's threading model, and, now, Linux's other deficiencies. > > His second argument is that if it starts having an effect, there > > is code that people have written that depends on it not having an > > effect, and where they handle every possible error return listed > > on the man page and in the POSIX.1 standard, *except* EAGAIN. And > > this code will break, and that breakage is a violation of POLA. > > > > I happen to disagree with this second argument. > > The most Unices ignore O_NONBLOCK for disk files. Cool with me. So they miss the optimization that's obviously possible in this area. > So I think programmers never use this flag and select()/etc for disk > files (because it's useless) and I think supporting this flag for disk > files should not break existent software. > But of course it creates portability problems. For FreeBSD's libc_r? You have got to be kidding, when you talk about portability of FreeBSD's libc_r! The effect in the old sigsched threads implementation from the comp.sources.unix archive would merely be to provide a latency optimization on the OS's which support it. I think that there is no portability problem; only that it would cause some software to run faster on FreeBSD than on other OS's, were it to be used. > > > states that O_NONBLOCKed regular disk file can return EAGAIN only > > > if there is a mandatory file/record lock. Solaris 8's man states the same. > > > > Actually, it does not say "only". It also says: [ ... ] > Yes, but there's no word about EAGAIN while a reading from a disk. You miss the point. The word "only" has very specific connotations in standards documents: it restricts permissable implementations. Because it did not actually use the word "only", it means that the implementation is not restricted from returning it where the behaviour is not specifically defined. As we see from the POSIX.1 standard quote, which you removed from your reply, it is *permissable* for a conforming UNIX implementation to return the error on disk files. For certain networking and storage subsystems (e.g. HSM), I would expect it to even be a *necessity*. -- Terry
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3E8CAD52.531E0A9>