I'm likely too rusty to even comment intelligently, but it seems to me this has been possible, in the cases of pipes and FD passing, and maybe FIFOs as well.
I recall having written these things in LiS to follow STREAMS standards; but every change to open/close/... may change those semantics. And I haven't done a thorough review lately. But I know I did have to address this issue (put another way, this topic rings a bell, however faintly).
What I am suggesting is that someone might check the old semantics for pipes and FD passing, and think about if/how they apply (or more recent semantics, for that matter). They may or may not be applicable; indeed, they may not even still be valid. I do think it's worth checking, though.
-John
Ragnar Paulson wrote:
Seeing as STREAMS pre-dates threads ... I don't know that this possibility has been defined in the API or even in SVID (isn't that the reference we all go back to?).
SCO suggests an error of EIO if getmsg() is called on a file descriptor that is in the process of closing. It's not clear what happens if the file descriptor is closed while getmsg is waiting ... before threads closing a file descriptor someone else is using wasn't possible and is not defined. It may well be that the results are OS specific and vary from OS to OS.
Fundamentally though ... isn't it an OS problem, not an LiS problem? What does Linux do in a thread if you close any file that another thread is reading?
I think either EIO or EBADF on the reader is a valid return ... but I think the OS should do it.
Ragnar
----- Original Message ----- From: "David Lehmann" <[EMAIL PROTECTED]> To: "David Grothe" <[EMAIL PROTECTED]> Cc: "Michael Shimony" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Wednesday, October 01, 2003 1:31 PM Subject: Re: [Linux-streams] LiS stuck in getmsg
David Grothe wrote:
I see where LiS makes no attempt to awaken a read/getmsg/ioctl upon close.
Any idea what the correct semantics are for close vs read/write/ioctl/getmsg/putmsg?
Does close wait until the other operations complete? or does close cause the other operations to abort?
The close causes the other operations to abort.
On Solaris, the same code works fine. i.e. The getmsg fails when another thread closes the file descriptor which getmsg is waiting on.
--
David Lehmann Ulticom, Inc. AOL/Yahoo IM: davidULCM 1020 Briggs Road 1-856-787-2729 Mt. Laurel, NJ 08054 USA
_______________________________________________ Linux-streams
mailing list [EMAIL PROTECTED] http://gsyc.escet.urjc.es/mailman/listinfo/linux-streams
_______________________________________________ Linux-streams mailing
list [EMAIL PROTECTED] http://gsyc.escet.urjc.es/mailman/listinfo/linux-streams
_______________________________________________ Linux-streams mailing list [EMAIL PROTECTED] http://gsyc.escet.urjc.es/mailman/listinfo/linux-streams
