Raymond Hettinger added the comment:
Marking this as closed/rejected for the reasons listed above.
Thank you all for the thoughtful and intelligent discussion.
--
resolution: -> rejected
stage: -> resolved
status: open -> closed
___
Python
Richard Whitehead added the comment:
Thanks João.
We are working on a medical prototype, and I wouldn't want to rely on our own
version of something so fundamental without having a thorough test harness for
it, which would obviously be quite time-consuming, and something of a dead-end.
I've
João Bernardo added the comment:
Don't keep your hopes up. People here don't like implementing features they
don't understand about even if they could verify elsewhere it works well.
My solution at the time was to create a decent "Condition" class based on the
original one (subclassing this
Richard Whitehead added the comment:
Condition.wait_for_any is still a desirable feature, e.g. to wait on multiple
command queues, or a work queue and a command queue.
Is there any chance of pulling this into the latest version?
--
nosy: +richardnwhitehead
João Bernardo added the comment:
Seems like just because I never used I don't support. Boost C++ libraries has
a wait_for_any functionality to synchronize futures. C# has a WaitAny in the
WaitHandle class (like our Condition).
Another problem is: the Condition class cannot be easily
Changes by Raymond Hettinger raymond.hettin...@gmail.com:
--
assignee: - rhettinger
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18078
___
___
João Bernardo added the comment:
I've been thinking about returning a list on wait_for_any, but that way you
will not be able to implement wait_for using it!
wait_for will return False on timeouts while wait_for_any will return a
list with some conditions(evaluates to True).
Also, wait_for
Raymond Hettinger added the comment:
FWIW, I don't support adding this functionality. I don't see precedents for
Condition Variables behaving this way in other languages. Also, I don't think
it is worth the added complexity, learning curve, and maintenance burden.
Condition variables are
Charles-François Natali added the comment:
FWIW, I don't support adding this functionality. I don't see precedents for
Condition Variables behaving this way in other languages. Also, I don't
think it is worth the added complexity, learning curve, and maintenance
burden. Condition
João Bernardo added the comment:
ping.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18078
___
___
Python-bugs-list mailing list
Unsubscribe:
Antoine Pitrou added the comment:
Charles-François's point about the algorithmic complexity is legitimate, so I
think he was actually waiting for you to amend your patch ;)
--
___
Python tracker rep...@bugs.python.org
João Bernardo added the comment:
Charles-François's point about the algorithmic complexity is
legitimate, so I think he was actually waiting for you to amend
your patch ;)
This doesn't seems to be the actual issue as it would require a big change for
something that wasn't proven
Richard Oudkerk added the comment:
IMHO
1) It should check all predicates.
2) It should return a list of ready conditions.
3) It should *not* accept a list of conditions.
4) from_condition() should be removed.
Also notify() should try again if releasing a waiter raises RuntimeError
because it
João Bernardo added the comment:
1) It should check all predicates.
OK. Maybe later there could be an option for customization?
2) It should return a list of ready conditions.
OK.
3) It should *not* accept a list of conditions.
The list option would be to simplify the wait method...
João Bernardo added the comment:
(ping)
It would be nice to have the feature on 3.4.
What changes should I do to the patch? Is anyone else working on that?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18078
Charles-François Natali added the comment:
I'm not convinced it's really useful.
Furthermore, the complexity is rather bad: if T is the average number
of waiting threads, an C the number of conditions being waited on, the
wait is O(C) (appending to C wait queues) and wakeup is O(CT) (C
removal
João Bernardo added the comment:
I'm not convinced it's really useful.
It doesn't seem a lot useful until you *really* need it. I've got 2 highly
parallel programs that took advantage of this pattern.
the wait is O(C) (appending to C wait queues) and wakeup
is O(CT) (C removal from a
Richard Oudkerk added the comment:
Furthermore, the complexity is rather bad: if T is the average number
of waiting threads, an C the number of conditions being waited on, the
wait is O(C) (appending to C wait queues) and wakeup is O(CT) (C
removal from a T-length deque).
Which just means
João Bernardo added the comment:
BTW, I think it would be better to have wait_for_any()
return a list of ready conditions rather than a boolean.
That was the original idea until I realized `wait` and `wait_for` were just
specializations of `wait_for_any`.
This can probably be done with
Charles-François Natali added the comment:
Which just means that waiting on C conditions is C times more expensive than
waiting on 1 currently is. That seems reasonable enough to me, and anyway,
I would expect C to be fairly small.
Waking up a single thread (through notify()) is currently
João Bernardo added the comment:
Here, removing a thread
from a wait queue other than the one from which it was signalled is
O(waiting threads).
To be fair, You will probably never have more than a few hundred/thousand
threads on a process. Usually you'll work under a few dozen threads.
To
João Bernardo added the comment:
Hi,
This code is working quite well on my system, but I'm still not sure if the
behavior of multiple predicates is the one other people want. So, for the
thread start running again:
- Should it test only the predicates from the awakened Conditions an accept if
Changes by Raymond Hettinger raymond.hettin...@gmail.com:
--
nosy: +rhettinger
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18078
___
___
João Bernardo added the comment:
I did what @Richard Oudkerk said and created the wait_for_any classmethod for
the Condition class.
Other Changes:
- I had to refactor wait and wait_for to be specializations of
wait_for_any.
- try...except on notify because the inner lock might have been
Changes by Serhiy Storchaka storch...@gmail.com:
--
nosy: +pitrou
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18078
___
___
Python-bugs-list
Antoine Pitrou added the comment:
I'm not sure what the point is. If you want to wake up a specific thread, you'd
probably be better off with a dedicated per-thread synchronization primitive
(either a Condition or something else).
--
nosy: +neologix
João Bernardo added the comment:
I usually have hundreds of threads waiting on a single Condition object and I
wake them with .notify_all()
Sometimes, I want a specific thread to wake from this condition and finish
their job apart from the others.
The problem is that I have 2 conditions to
Richard Oudkerk added the comment:
BTW, I find .notify(N) not much useful, because the docs say it may wake
more threads on a different implementation and also I can't never know
whom am I waking.
The fact that more than N threads can wake up is not a problem if you are
retesting an
João Bernardo added the comment:
But it might be nice to be able to wait on multiple conditions at
once, assuming they are associated with the same lock. Maybe we could
have a static method
This could solve the waiting problem for the thread, but also may keep the
other Condition objs
Richard Oudkerk added the comment:
This could solve the waiting problem for the thread, but also may
keep the other Condition objs waiting -- and that may not be problem
because I'm already using .notify_all()
I don't understand what you mean.
Probably this function have more use cases
João Bernardo added the comment:
It would be for waiting for several conditions associated with the
same lock, not for waiting for several locks.
A Condition uses a 2 lock mechanism:
- outer lock: one for all the waiters to access the Condition object
- inner lock: one for each waiter
Richard Oudkerk added the comment:
You cannot associate several conditions to the *inner lock*, because you
don't have access to them (otherwise I wouldn't open this issue).
Condition.wait_for_any() would create a single inner lock and add it to the
_waiters list for each of the condition
João Bernardo added the comment:
Condition.wait_for_any() would create a single inner lock and add it
to the _waiters list for each of the condition variables
Now I see your point!
Could it also have one (optional) argument so I can provide this lock myself?
while expr:
New submission from João Bernardo:
If users could provide an inner lock for `threading.Condition` acquire when
making a thread wait, it would allow for notifying a specific waiter.
Because of race conditions, using:
cond.notify(1)
may not wake the thread I want. Also, I may not want to
34 matches
Mail list logo
