libthr and 1:1 threading.

[Terry Lambert]

Igor Sysoev wrote:
> On Thu, 3 Apr 2003, Terry Lambert wrote:
> > I have to ask:
> >
> > Why is it so important to people that the libthr performance
> > gains be impossible to achieve without use of the 1:1 model,
> > rather than a modification of libc_r, or avoidance of existing
> > kernel latencies?
> 
> If you mean that "people" is my humble person then I want to say
> that I am not against 1:1 model libthr, KSE's M:N model, current
> or improved libc_r, rfork()ed LinuxThreads and any possible future
> threads implementation.

I didn't mean you specifically.


> My last emails were caused only by your incorrect statements about
> a non-blocking behaviour of Solaris disk files.

When you referenced Solaris 8, rather than contradicting you, I
looked at the source code and immediately admitted that I was
wrong and you were right, so I don't see why this has continued.

Can you do the same with regard to the fact that, even if the
current implementation does not use the flag in its implementation
of disk I/O, that it does not prohibit setting the flag, and it
does not prohibit a third party, such as Veritas or some other
disk FS provider, from implementing it?

As I said before, I used this flag to great effect on SVR4.0.2
and SVR4.3 in the NetWare for UNIX product in 1994: it provided
a 12% performance improvement, by prefaulting the first 9K of
Windows executable files stored on Novell servers, and accessed
from Windows (Windows repeatedly re-references the first 9K in
loading executables, or used to in the WIN32 and Windows95 era).

At the time, the effect was measurable on Solaris as well, and
it was designed with the source code to the OS in hand for both
SVR4 and Solaris, which had just been finished being jointly
integrated at the time.

That Solaris can't do this any more in more recent versions of
Solaris is a loss of functionality, not a feature.

-- Terry