One other comment - I don't think I'd use SCO as a reference for this. I know that fairly modern versions of SCO didn't have pipes and FD passing, and may not have even had FIFOs, and I've never heard that they were ever added. I vaguely recall reviewing SCO's semantics and concluding that I wasn't surprised they didn't have them, and that their semantics for open/close were part of that issue. But I'm talking '2000, when I first did pipes/FD passing for LiS, and things might have changed since then.
-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
