On Thu, 20 Mar 2003, Oliver Neukum wrote:
were doing it, I'd not use the synchronous unlink call;
ought not to matter, but we can be more sure than that.
That's dangerous. We must have absolute confidence about whether
the message has gone over the wire or not.
Suppose it's a reset. We'd
Am Donnerstag, 20. März 2003 17:03 schrieb Alan Stern:
On Thu, 20 Mar 2003, Oliver Neukum wrote:
were doing it, I'd not use the synchronous unlink call;
ought not to matter, but we can be more sure than that.
That's dangerous. We must have absolute confidence about whether
the message
Here's an updated version of Oliver's patch, changing:
- uses struct completion for simplicity
- the wait_event_timeout() logic is now like the other macros
which can return before the event happens: returns a value
- clarity for MAX_SCHEDULE_TIMEOUT scenarios, by using the
standard
Hi Dave,
does this remove your doubts about race conditions in the synchronous API?
Regards
Oliver
You can import this changeset into BK by piping this whole message to:
'| bk receive [path to repository]' or apply the patch as usual.
From: Oliver Neukum [EMAIL PROTECTED]
Date: Wed, 19 Mar 2003 21:44:10 +0100
+#define __wait_event_timeout(wq, condition, ret) \
+ if (condition) \
+ break; \
Am Mittwoch, 19. März 2003 22:00 schrieb Pete Zaitcev:
From: Oliver Neukum [EMAIL PROTECTED]
Date: Wed, 19 Mar 2003 21:44:10 +0100
+#define __wait_event_timeout(wq, condition, ret) \
+ if (condition) \
+
From: Oliver Neukum [EMAIL PROTECTED]
Date: Wed, 19 Mar 2003 22:13:07 +0100
From: Oliver Neukum [EMAIL PROTECTED]
Date: Wed, 19 Mar 2003 21:44:10 +0100
+#define __wait_event_timeout(wq, condition, ret) \
+ if (condition)
Oliver Neukum wrote:
Hi Dave,
does this remove your doubts about race conditions in the synchronous API?
It's a lot closer ... I'll try it. Yes, it's odd that there
was no pre-existing wait_event_timeout(), and that's the
call we need to make that implementation behave right.
Some further
Am Mittwoch, 19. März 2003 23:39 schrieb David Brownell:
Oliver Neukum wrote:
Hi Dave,
does this remove your doubts about race conditions in the synchronous
API?
It's a lot closer ... I'll try it. Yes, it's odd that there
was no pre-existing wait_event_timeout(), and that's the
call
