Date: Thu, 03 Apr 2003 06:19:26 -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: <3E8C42EE.C3602A39@mindspring.com> References: <Pine.BSF.4.21.0304031659020.32175-100000@is>
next in thread | previous in thread | raw e-mail | index | archive | help
Igor Sysoev wrote: > I did not say about read() operation. I said about some user land CPU > instruction that accessed a page that is not in a memory. This instruction > causes page fault. I treated this case seperately, lower down in the message. > > O_NONBLOCK. > > > > Examining the Solaris 8 sources, it seems to have been removed from > > the disk I/O modules, and applies only to socktpi.c, ptm.c, audio_mc.c, > > ecpp.c, and envctrl.c. Apparently, it's also missing from the tty > > code, which goes against what Matt claimed, actually. > > If Solaris 8's stdin handled by tty code then tty supports O_NONBLOCK: [ ... test program ... ] 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. Matt's first argument is that the flag has no effect on disk files in FreeBSD; I don't dispute that, and never did. 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. > This Solaris 2.4's readv() man > http://www.doc.ic.ac.uk/~mac/manuals/solaris-manual-pages/solaris/usr/man/man2/read.2.html > 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, ity does not say "only". It also says: EAGAIN Total amount of system memory available when reading using raw I/O is temporarily insuffi- cient. Now let me point you to the POSIX standard and the Single UNIX Specification, which says: http://www.opengroup.org/onlinepubs/007908799/xsh/read.html When attempting to read a file (other than a pipe or FIFO) that supports non-blocking reads and has no data currently available: o If O_NONBLOCK is set, read() will return a -1 and set errno to [EAGAIN]. o If O_NONBLOCK is clear, read() will block the calling thread until some data becomes available. o The use of the O_NONBLOCK flag has no effect if there is some data available. Now we are just arguing about "supports non-blocking reads". But it's gets better later in the man page: ERRORS The read(), pread() and readv() functions will fail if: [EAGAIN] The O_NONBLOCK flag is set for the file descriptor and the process would be delayed. This confirms that it is a descriptor attribute, not an underlying object attribute, in the general sense, and that the *intent* is to permit detection and avoidance of delays. > > Or the USL SVR4.0.2 or SVR4.2 source code? > > No, I have not an access to this source code. > But if you have an access to these systems it's easy to check whethear > these systems supports O_NONBLOCK on disk files or not. Try redirecting your test program from a file. It's just a flag. My Solaris 8 source code and Solaris 8 SPARC box both allow it to be set on a file, even if it has no effect. > > > And what do you suppose to do in a signal handler ? > > > Using some non-reenterant library functions ? > > > > No. Call the user thread scheduler as a result of a fault that > > is normally not trappable because it resulted from a memory access > > to an mmap()'ed region of the address space, rather than resulting > > from an explicit system call. There is no system call context when > > a trap like that occurs, there is only a trap context. > > This is the same thing that KSE M:N model does with page faults. > It upcalls UTS when a thread blocked on a pagein operation. Yes. It's another way to leverage the existing kernel KSE code into getting higher performance on a UP box, without going to using libthr instead of libc_r. -- Terry
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3E8C42EE.C3602A39>