no return value for threading.Condition.wait(timeout)?

[Piet van Oostrum]

>>>>> Gabriel Rossetti <gabriel.rossetti at arimaz.com> (GR) wrote:

>GR> Piet van Oostrum wrote:
>>>>>>>> Gabriel Rossetti <gabriel.rossetti at arimaz.com> (GR) wrote:
>>>>>>>> 
>>> 
>>> 
>GR> I have a 1-1 relation, I have a thread reading msgs from a network socket
>GR> and a method waiting for an answer to arrive (see my thread
>GR> "Threading.Condition problem"). I would like to be able to have a timeout
>GR> as to not block forever, so the idea is to check if I returned because of a
>GR> timeout or not.
>>>> 
>>> 
>>> So that case is easy I think. After the wait just check if the answer
>>> has arrived.
>>> 
>GR> The problem is other answers could arrive that are not the one I
>GR> want. Maybe I could check if I got the answer, if not then check
>GR> how much time has elapsed, and if it's grater or equal to the
>GR> timeout consider it a timeout. I still think a return value would
>GR> be better though.

The wait will not get a return value in Python. There was an issue
posted in the tracker to request this in 2005. Recently (after 4 years)
it was rejected by the BDFL. See http://bugs.python.org/issue1175933

OK, your use case might be a bit more difficult, but I still think it
can be solved without a return value. I can't tell exactly how because
of lack of information.

So (as I already mentioned in one of my previous messages) being
notified doesn't imply that everything is OK. Now suppose that your CV
is notified one microsecond before it would time out but the required
answer did not arrive. What's the difference with a real timeout except
for that microsecond?

Reimplementing Condition yourself is not to be recommended I think.
Using these synchronisation primitives is hard enough let alone
implementing them. 
-- 
Piet van Oostrum <piet at cs.uu.nl>
URL: http://pietvanoostrum.com [PGP 8DAE142BE17999C4]
Private email: piet at vanoostrum.org