![]() | |||||||||||||
Messages in this thread |
Rusty Russell, Wed, Aug 27, 2003 04:40:14 +0200: > In message <20030826092631.GN16080@Synopsys.COM> you write: > > Rusty Russell, Tue, Aug 26, 2003 05:05:56 +0200: > > > Hi Andrew, Ingo, > > > > > > This was posted before, but dropped. > > > > > > Name: Minor futex comment tweaks and cleanups > > > Author: Rusty Russell > > > Status: Tested on 2.6.0-test4-bk2 > > > > > > D: Changes: > > > D: > > > D: (1) don't return 0 from futex_wait if we are somehow > > > D: spuriously woken up, return -EINTR on any such case, > > > > Here. EINTR is often (if not always) assumed to be caused by a signal. > > And someone may rightfully depend on it being that way. > > Yes. Changed code to loop in this case. I don't know of anyone who > actually randomly wakes processes, but just in case. Returning "0" > always means as "you were woken up by someone using FUTEX_WAKE", and > some callers *need to know*. > > How's this? Now it's consistent with what EINTR conventionally mean :) > Rusty. > -- ... > + > + /* Were we woken up (and removed from queue)? Always return > + * success when this happens. */ > if (!unqueue_me(&q)) > ret = 0; > - put_page(q.page); > + else if (time == 0) > + ret = -ETIMEDOUT; > + else if (signal_pending(current)) > + ret = -EINTR; > + else > + /* Spurious wakeup somehow. Loop. */ > + goto again; > > return ret; Btw, what could that spurious wakeups be? It set to loop unconditionally, so if the source of wakeup insists on wakeing up the code could result in endless loop, right? -alex - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ | ||||||||||||
| Last update: 2005-03-22 13:48 [from the cache] ©2003-2008 | |||||||||||||