[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: threads
From:       Stephan Kulow <coolo () kde ! org>
Date:       1999-12-03 14:41:47
[Download RAW message or body]

Waldo Bastian wrote:
> 
> On Fri, 03 Dec 1999, Stephan Kulow wrote:
> > "Dirk A. Mueller" wrote:
> > >
> > > On Fre, 03 Dez 1999, Simon Hausmann wrote:
> > >
> > > > I'll revert my patches, ok?
> > >
> > > Why not make it configurable? I don't use NFS, so I personally don't care
> > > about the problems with it. But I would like to have the speed :-)
> > >
> > > even a compilation time switch would be ok for me.
> > >
> > Why everyone says this is a NFS only problem is above me. NFS just
> > increases
> > the factor, if you have twice as many files on your harddisc as on your
> > NFS server the speed (and the problem) is the same
> 
> No. The problem is that there is no way you can reasonably abort your
> application when it is being blocked on a slow NFS access.
> 
> Reading a directory with 2000 files might be slow, but if you do a
> processEvents() once in a while you still have the possibility to abort when
> the user presses some cancel button.
> 
> When you are inside a system call which waits for a remote NFS server to answer
> you can do nothing.
> 
> That's the difference between being slow (large dir) and being blocked (NFS).
You can have the same without NFS. Suspended discs, automounted zip
discs, zip
discs in general... :)

BTW: I'm currently hacking kfile to fork in case I expect the trouble
above.
If it works, thanks go to Olaf Kirch for a very clear analysis and
providing
code :)

Greetings, Stephan

-- 
As long as Linux remains a religion of freeware fanatics,
Microsoft have nothing to worry about.  
                       By Michael Surkan, PC Week Online

[prev in list] [next in list] [prev in thread] [next in thread]