Am Donnerstag, 6. Dezember 2007 12:39 schrieb David Miller:
> > Because you just will put enough RAM modules into you server when
> > setting up a scalable system.
>
> This suggestion is avoiding the important semantic issue, and
> won't lead to a real discussion of the core problem.
When writing applications for unix operating systems, it is known since ages
that stuff can be swapped out and that even things like memory accesses can
block. So it does not really surprise when a system call has to wait for
memory - just imagine the kernel code for connect() could be and has been
swapped out.
Even with moderate swap activity, this memory should be available in much less
than one second. If on the other hand the system is already threshing, it is
no difference if it does so within connect() or while reaching the connect()
system call in the application flow.
Btw, this is where admin responsibility to size their systems kicks in.
So where I would draw the line: connect() is clearly a network related
function. Therefore, if a nonblocking connect() has to sleep for a local,
controllable resource like memory to become available, this is ok. Maybe it
shouldn't wait for a 128MB buffer if someone configured such an abonimation,
haven't thought deeply about that. But when being told not to wait the
connection to complete, it should never ever wait for another network related
activity like IPSEC SA setup to complete, especially not for hours.
IMHO this is what developers expect, and is also consistent with the fact that
POSIX does not define O_NONBLOCK behaviour for local files.
Stefan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
