libthr and 1:1 threading.

Terry Lambert tlambert2 at mindspring.com
Thu Apr 3 06:23:06 PST 2003


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


More information about the freebsd-arch mailing list