summaryrefslogtreecommitdiffstats
path: root/misc
Commit message (Collapse)AuthorAgeFilesLines
* ring: use a different type for read/write pointerswm42014-05-301-3/+3
| | | | | | uint_least32_t could be larger than uint32_t, so the return values of mp_ring_get_wpos/rpos must be adjusted. Actually just use unsigned long as type instead, because that is less awkward than uint_least32_t.
* ring: implement drain in terms of readwm42014-05-291-12/+9
| | | | | I think this makes it easier to reason about it and avoids duplicate logic.
* Fix gcc 4.7 warning about shadowing talloc_parent in mp_dispact_queuePaweł Forysiuk2014-05-281-2/+2
|
* atomics: switch to C11 stdatomic.hwm42014-05-211-13/+8
| | | | | | | | | | | | | | | | | | | | | | | | | In my opinion, we shouldn't use atomics at all, but ok. This switches the mpv code to use C11 stdatomic.h, and for compilers that don't support stdatomic.h yet, we emulate the subset used by mpv using the builtins commonly provided by gcc and clang. This supersedes an earlier similar attempt by Kovensky. That attempt unfortunately relied on a big copypasted freebsd header (which also depended on much more highly compiler-specific functionality, defined reserved symbols, etc.), so it had to be NIH'ed. Some issues: - C11 says default initialization of atomics "produces a valid state", but it's not sure whether the stored value is really 0. But we rely on this. - I'm pretty sure our use of the __atomic... builtins is/was incorrect. We don't use atomic load/store intrinsics, and access stuff directly. - Our wrapper actually does stricter typechecking than the stdatomic.h implementation by gcc 4.9. We make the atomic types incompatible with normal types by wrapping them into structs. (The FreeBSD wrapper does the same.) - I couldn't test on MinGW.
* 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-232-0/+274
| | | | | | | 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).
* charset_conv: mp_msg conversionswm42013-12-212-23/+28
|
* Split mpvcore/ into common/, misc/, bstr/wm42013-12-174-0/+552
generated by cgit v1.2.3 (git 2.25.1) at 2024-04-27 21:58:15 +0000