github
/
mpv
mirror of https://github.com/mpv-player/mpv
1
Fork 0
Code Releases Activity
mpv/misc/dispatch.h

33 lines
1.5 KiB
C
Raw Normal View History

dispatch: move into its own source file This was part of osdep/threads.c out of laziness. But it doesn't contain anything OS dependent. Note that the rest of threads.c actually isn't all that OS dependent either (just some minor ifdeffery to work around the lack of clock_gettime() on OSX).
2014-04-23 20:37:57 +02:00
#ifndef MP_DISPATCH_H_
#define MP_DISPATCH_H_
player: remove in_dispatch field (Not sure if worth the trouble, but it does seem less awkward.)
2018-04-15 11:43:49 +02:00
#include <stdint.h>
dispatch: move into its own source file This was part of osdep/threads.c out of laziness. But it doesn't contain anything OS dependent. Note that the rest of threads.c actually isn't all that OS dependent either (just some minor ifdeffery to work around the lack of clock_gettime() on OSX).
2014-04-23 20:37:57 +02:00
typedef void (*mp_dispatch_fn)(void *data);
struct mp_dispatch_queue;
struct mp_dispatch_queue *mp_dispatch_create(void *talloc_parent);
void mp_dispatch_set_wakeup_fn(struct mp_dispatch_queue *queue,
void (*wakeup_fn)(void *wakeup_ctx),
void *wakeup_ctx);
dispatch: add strange mechanism for making worker threads responsive This is probably a sin for the sake of user experience. See a following commit that wires up f_decoder_wrapper with it.
2020-03-05 21:05:14 +01:00
void mp_dispatch_set_onlock_fn(struct mp_dispatch_queue *queue,
void (*onlock_fn)(void *onlock_ctx),
void *onlock_ctx);
dispatch: move into its own source file This was part of osdep/threads.c out of laziness. But it doesn't contain anything OS dependent. Note that the rest of threads.c actually isn't all that OS dependent either (just some minor ifdeffery to work around the lack of clock_gettime() on OSX).
2014-04-23 20:37:57 +02:00
void mp_dispatch_enqueue(struct mp_dispatch_queue *queue,
mp_dispatch_fn fn, void *fn_data);
void mp_dispatch_enqueue_autofree(struct mp_dispatch_queue *queue,
mp_dispatch_fn fn, void *fn_data);
options: add a thread-safe way to notify option updates So far, we had a thread-safe way to read options, but no option update notification mechanism. Everything was funneled though the main thread's central mp_option_change_callback() function. For example, if the panscan options were changed, the function called vo_control() with VOCTRL_SET_PANSCAN to manually notify the VO thread of updates. This worked, but's pretty inconvenient. Most of these problems come from the fact that MPlayer was written as a single-threaded program. This commit works towards a more flexible mechanism. It adds an update callback to m_config_cache (the thing that is already used for thread-safe access of global options). This alone would still be rather inconvenient, at least in context of VOs. Add another mechanism on top of it that uses mp_dispatch_queue, and takes care of some annoying synchronization issues. We extend mp_dispatch_queue itself to make this easier and slightly more efficient. As a first application, use this to reimplement certain VO scaling and renderer options. The update_opts() function translates these to the "old" VOCTRLs, though. An annoyingly subtle issue is that m_config_cache's destructor now releases pending notifications, and must be released before the associated dispatch queue. Otherwise, it could happen that option updates during e.g. VO destruction queue or run stale entries, which is not expected. Rather untested. The singly-linked list code in dispatch.c is probably buggy, and I bet some aspects about synchronization are not entirely sane.
2017-08-22 15:50:33 +02:00
void mp_dispatch_enqueue_notify(struct mp_dispatch_queue *queue,
mp_dispatch_fn fn, void *fn_data);
void mp_dispatch_cancel_fn(struct mp_dispatch_queue *queue,
mp_dispatch_fn fn, void *fn_data);
dispatch: move into its own source file This was part of osdep/threads.c out of laziness. But it doesn't contain anything OS dependent. Note that the rest of threads.c actually isn't all that OS dependent either (just some minor ifdeffery to work around the lack of clock_gettime() on OSX).
2014-04-23 20:37:57 +02:00
void mp_dispatch_run(struct mp_dispatch_queue *queue,
mp_dispatch_fn fn, void *fn_data);
void mp_dispatch_queue_process(struct mp_dispatch_queue *queue, double timeout);
player: use better way to wait for input and dispatching commands Instead of using input_ctx for waiting, use the dispatch queue directly. One big change is that the dispatch queue will just process commands that come in (e.g. from client API) without returning. This should reduce unnecessary playloop excutions (which is good since the playloop got a bit fat from rechecking a lot of conditions every iteration). Since this doesn't force a new playloop iteration on every access, this has to be enforced manually in some cases. Normal input (via terminal or VO window) still wakes up the playloop every time, though that's not too important. It makes testing this harder, though. If there are missing wakeup calls, it will be noticed only when using the client API in some form. At this point we could probably use a normal lock instead of the dispatch queue stuff.
2016-09-16 14:25:50 +02:00
void mp_dispatch_interrupt(struct mp_dispatch_queue *queue);
player: remove in_dispatch field (Not sure if worth the trouble, but it does seem less awkward.)
2018-04-15 11:43:49 +02:00
void mp_dispatch_adjust_timeout(struct mp_dispatch_queue *queue, int64_t until);
dispatch: move into its own source file This was part of osdep/threads.c out of laziness. But it doesn't contain anything OS dependent. Note that the rest of threads.c actually isn't all that OS dependent either (just some minor ifdeffery to work around the lack of clock_gettime() on OSX).
2014-04-23 20:37:57 +02:00
void mp_dispatch_lock(struct mp_dispatch_queue *queue);
void mp_dispatch_unlock(struct mp_dispatch_queue *queue);
#endif