On Sun, 27 Aug 2000 kuznet@ms2.inr.ac.ru wrote:
> Hello!
>
> > too fscking bad, but close() is unlikely to get you out of that. If it
> > isn't - what are you complaining about?
>
> Sorry. close() is the only way to do this. 8)
What had happened with kill()? Sorry, I don't buy that argument - "we
shouldn't leave the process in hanging state - we don't, they are not
hung - oh, but if we put a process into such situation we will have to
use signals [or sendto(), or... depending on the case in question] and
we'ld like to use close()". Kernel doesn't leave them hung. Not more than
it does on read() from the pipe where writer doesn't want to write().
Should we declare read() broken because of (while true; do; done)|grep?
> I had to break semantics of shutdown() making it working
> on not-connected sockets to help these folks.
>
> > Excuse me? Sorry, but you've totally misread that code. If the last owner
> > of mm_struct exits while the thing is in use by some processor running
> > lazy-TLB process... Guess what - mm_struct hangs around until the next
> > context switch to non-lazy beast. On all CPUs that had it.
>
> The situation is the same _exactly_.
>
> The only thing, why f_count, fget() and fput() are required
> is to hold temporary references, when kernel cannot allow
> destruction.
?
> User references must be counted separately.
>
> Actually, Linus seems to forget about his own idea
> of returning valid error from close(). Think, how it is possible
> to return valid error, when fput() is used to close file.
SCM_RIGHTS cookies. mmap. fork(), for that matter.
> Also, lingering (i.e. waiting for looong time) in fput() smells
> interesting. 8)
Yes? Receiving process doesn't care to do recvmsg() on SCM_RIGHTS
datagram. What should happen on close(), again?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Aug 31 2000 - 21:00:19 EST