Date: Mon, 07 Apr 2003 04:35:41 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: Igor Sysoev <is@rambler-co.ru> Cc: freebsd-threads@freebsd.org Subject: Re: libc_r and non-blocking disk I/O Message-ID: <3E91628D.6D0D7D3C@mindspring.com> References: <Pine.BSF.4.21.0304071202520.40397-100000@is>
next in thread | previous in thread | raw e-mail | index | archive | help
[ 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3E91628D.6D0D7D3C>