diff options
author | wm4 <wm4@nowhere> | 2014-06-07 10:44:21 +0200 |
---|---|---|
committer | wm4 <wm4@nowhere> | 2014-06-07 15:57:47 +0200 |
commit | a1000962e3ef3e4cf3f6ade8702ce055b38872a9 (patch) | |
tree | da8050c203f0744dfac71f32f170c85c7659d95f /player/client.c | |
parent | 60e0833f1fe976b0bbb74aa60980bfb36d828dee (diff) | |
download | mpv-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.c | 5 |
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) |