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
