libthr and 1:1 threading.

[Terry Lambert]

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