libc_r and non-blocking disk I/O

[Terry Lambert]

[ Moved to freebsd-threads, where it should have been posted in
  the first place ]

Igor Sysoev wrote:
> I mean that if FreeBSD would support select() for disk files there can
> be the programs that will use this feature directly without any wrappers
> and these programs would have the portability problems.

Select will simply return "true" for disk files on all systems
that don't support the idea of "disk I/O in progress/disk I/O
complete".

Such systems would eat the 20ms stall that FreeBSD is eating
today in lib_r's non-blocking I/O case.

Therefore code written to expect this behaviour will work
portably on all systems; as you note, worst case, there's
an extra (useless) call to select(), which harms nothing.


> It's something like some Linux programs use a specific signal
> behaviour of Linux clone()d pthreads.

We could enumerate portability issues until we has 5 foot beards;
a benign select() is much less of an issue than, for example, the
fact that Linux programmers often fail to bzero() sockaddr_in's
they declare on the stack, because Linux works without you doing
that, and FreeBSD, SVR4, Solaris, etc., do not.

I don't think it's useful to call a benign select() a "portability
problem"; certainly, it's not in the same class as malignant
portability issues with signals or sockaddr_in's, etc..

-- Terry