2014-04-23 18:37:57 +00:00
|
|
|
#ifndef MP_DISPATCH_H_
|
|
|
|
|
#define MP_DISPATCH_H_
|
|
|
|
|
|
|
|
|
|
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);
|
|
|
|
|
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 13:50:33 +00: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);
|
2014-04-23 18:37:57 +00: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);
|
2016-09-16 12:25:50 +00:00
|
|
|
void mp_dispatch_interrupt(struct mp_dispatch_queue *queue);
|
2014-04-23 18:37:57 +00:00
|
|
|
void mp_dispatch_lock(struct mp_dispatch_queue *queue);
|
|
|
|
|
void mp_dispatch_unlock(struct mp_dispatch_queue *queue);
|
|
|
|
|
|
|
|
|
|
#endif
|