summaryrefslogtreecommitdiffstats
path: root/player/client.c
diff options
context:
space:
mode:
authorwm4 <wm4@nowhere>2014-06-07 10:44:21 +0200
committerwm4 <wm4@nowhere>2014-06-07 15:57:47 +0200
commita1000962e3ef3e4cf3f6ade8702ce055b38872a9 (patch)
treeda8050c203f0744dfac71f32f170c85c7659d95f /player/client.c
parent60e0833f1fe976b0bbb74aa60980bfb36d828dee (diff)
downloadmpv-a1000962e3ef3e4cf3f6ade8702ce055b38872a9.tar.bz2
mpv-a1000962e3ef3e4cf3f6ade8702ce055b38872a9.tar.xz
client API: change mpv_wait_event() timeout semantics
Now a negative timeout mean an infinite timeout. This is similar to the poll() system call. Apparently this is more intuitive and less confusing than specifying a "very high" value as timeout if you want to wait forever. For callers that never pass negative timeouts, nothing changes.
Diffstat (limited to 'player/client.c')
-rw-r--r--player/client.c5
1 files changed, 4 insertions, 1 deletions
diff --git a/player/client.c b/player/client.c
index fad3d89a93..be8cbc5d88 100644
--- a/player/client.c
+++ b/player/client.c
@@ -495,6 +495,9 @@ mpv_event *mpv_wait_event(mpv_handle *ctx, double timeout)
{
mpv_event *event = ctx->cur_event;
+ if (timeout < 0)
+ timeout = 1e20;
+
int64_t deadline = mp_add_timeout(mp_time_us(), timeout);
pthread_mutex_lock(&ctx->lock);
@@ -535,7 +538,7 @@ mpv_event *mpv_wait_event(mpv_handle *ctx, double timeout)
}
if (ctx->queued_wakeup)
break;
- if (timeout <= 0)
+ if (timeout == 0)
break;
int r = mpthread_cond_timedwait(&ctx->wakeup, &ctx->lock, deadline);
if (r == ETIMEDOUT)