summaryrefslogtreecommitdiffstats
path: root/misc/dispatch.c
Commit message (Collapse)AuthorAgeFilesLines
* threads: use utility+POSIX functions instead of weird wrapperswm42015-05-111-1/+2
| | | | | | | There is not much of a reason to have these wrappers around. Use POSIX standard functions directly, and use a separate utility function to take care of the timespec calculations. (Course POSIX for using this weird format for time values.)
* Fix gcc 4.7 warning about shadowing talloc_parent in mp_dispact_queuePaweł Forysiuk2014-05-281-2/+2
|
* threads: use mpv time for mpthread_cond_timedwait wrapperwm42014-05-181-4/+6
| | | | | | Use the time as returned by mp_time_us() for mpthread_cond_timedwait(), instead of calculating the struct timespec value based on a timeout. This (probably) makes it easier to wait for a specific deadline.
* dispatch: document some guaranteeswm42014-04-251-0/+4
| | | | | | | | The here documented guarantee might simplify code using this mechanism a lot, because it becomes unnecessary to invent a separate mechanism to make the mp_dispatch_queue_process loop exit after processing a dispatch callback. (Instead, the dispatch callback can set a flag, and the caller of mp_dispatch_queue_process can check it.)
* dispatch: wakeup only if needed on mp_dispatch_resume()wm42014-04-241-1/+3
| | | | | | | | The wakeup is needed to make mp_dispatch_queue_process() return if suspension is not needed anymore - which is only the case when the request count reaches 0. The assertion added with this commit always has/had to be true.
* dispatch: improve documentation commentswm42014-04-231-8/+10
|
* threads: fix function namewm42014-04-231-1/+1
| | | | Closer to the corresponding standard function pthread_cond_timedwait.
* dispatch: implement timeoutwm42014-04-231-6/+11
| | | | | | | | | | | | | Note that this mechanism is similarly "unreliable" as for example pthread_cond_timedwait(). Trying to target the exact wait time will just make it more complex. The main use case for this is for threads which either use the dispatch centrally and want mp_dispatch_queue_process to do a blocking wait for new work, or threads which have to implement timers. For the former, anything is fine, as long as they don't have to do active waiting for new works. For the former, callers are better off recalculating their deadline after every call.
* dispatch: use a real lock for mp_dispatch_lock()wm42014-04-231-37/+20
| | | | | | | | | | | This is much simpler, leaves fairness isues etc. to the operating system, and will work better with threading-related debugging tools. The "trick" to this is that the lock can be acquired and held only while the queue is in suspend mode. This way we don't need to make sure the lock is held outside of mp_dispatch_queue_process, which would be quite messy to get right, because it would have to be in locked state by default.
* dispatch: fix broken lockingwm42014-04-231-0/+7
| | | | | | | | | | | | | | mp_dispatch_queue_process() releases the queue->lock mutex while processing a dispatch callback. But this allowed mp_dispatch_lock() to grab the "logical" lock represented by queue->locked. Grabbing the logical lock is not a problem in itself, but it can't be allowed to happen while the callback is still running. Fix this by claiming the logical lock while the dispatch callback is processed. Also make sure that the thread calling mp_dispatch_lock() is woken up properly. Fortunately, this didn't matter, because the locking function is unused.
* dispatch: wakeup target thread when locking/suspendingwm42014-04-231-1/+16
| | | | | Without this, it could happen that both the caller thread and the target thread sleep.
* dispatch: move into its own source filewm42014-04-231-0/+251
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).
generated by cgit v1.2.3 (git 2.25.1) at 2024-05-01 23:55:51 +0000