lkml.org 
[lkml]   [2000]   [Aug]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] thread wakeup fix for 2.4.0-test7


On Sun, 27 Aug 2000, Rusty Russell wrote:

> Tested 2.2.15 (fd closed, data becomes available)
> 1) read returns as normal
> 2) poll returns POLLNVAL, even if it's readable.

... unless ufds had been swapped out and close() happens from another
thread while we are paging it in before copying the data out.

> 3) select will not return EBADF, nor mark fd readable, even if it's
> readable.

Ditto.

> AFAICT our behaviour doesn't violate POSIX (although it differs from
> Solaris), so the question is: is it OK to leave it as undefined
> behavior, and say any program relying on it is buggy?

About the only case when program's behaviour is _not_ undefined with such
scenario is the following:

thread A:
poll() on array including descriptor n
thread B:
close(n);do something that leads to event on file that used to be
refered by n
everything else:
make damn sure that no events on that file will happen until B
will do its thing.

Subtle, britlle and nonportable.

-
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/

\
 
 \ /
  Last update: 2005-03-22 12:38    [W:0.054 / U:3.340 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site