summaryrefslogtreecommitdiffstats
path: root/input/ipc-unix.c
Commit message (Collapse)AuthorAgeFilesLines
* options: get rid of GLOBAL_CONFIG hackwm42019-11-291-1/+1
| | | | | | | Just an implementation detail that can be cleaned up now. Internally, m_config maintains a tree of m_sub_options structs, except for the root it was not defined explicitly. GLOBAL_CONFIG was a hack to get access to it anyway. Define it explicitly instead.
* Merge commit '559a400ac36e75a8d73ba263fd7fa6736df1c2da' into ↵Anton Kindestam2018-12-051-2/+5
|\ | | | | | | | | | | wm4-commits--merge-edition This bumps libmpv version to 1.103
| * player: get rid of mpv_global.optswm42018-05-241-2/+5
| | | | | | | | | | | | | | | | This was always a legacy thing. Remove it by applying an orgy of mp_get_config_group() calls, and sometimes m_config_cache_alloc() or mp_read_option_raw(). win32 changes untested.
* | ipc-unix: don't blow up on readonly fd://Niklas Haas2018-10-311-1/+1
| | | | | | | | | | | | On my system, when trying to use mpv with a read-only fd created by python 3.7, `send` triggers ENOTSOCK, not EBADF. Extend the logic to detect non-writable fds by this `errno`.
* | ipc-unix: leave room for a NUL terminatorBen Boeckel2018-10-311-1/+1
|/ | | | | | | The `strncpy` function will not always place a terminating `NUL` if the source is longer than the destination buffer. Instead, let `strncpy` truncate as it normally would, but leave the last byte alone (it is zero-initialized when declared).
* all: replace mpv_detach_destroy() with mpv_destroy()wm42018-03-151-2/+2
|
* ipc: avoid dereferencing NULLMartin Shirokov2017-12-151-7/+17
| | | | | This can happen when ctr->client_api->shutting_down is set to true, or when there are over 1000 clients with the same name passed to mp_new_client().
* Avoid calling close(-1)wm42017-06-291-2/+4
| | | | | | | | | | While this is perfectly OK on Unix, it causes annoying valgrind warnings, and might be otherwise confusing to others. On Windows, the runtime can actually abort the process if this is called. push.c part taken from a patch by Pedro Pombeiro.
* ipc-unix: don’t truncate the message on EAGAINSebastian Reuße2017-05-241-4/+1
| | | | Fixes #4452.
* ipc: log when listening to IPC socketwm42016-09-291-0/+2
| | | | Fixes #3598.
* client API: declare mpv_suspend/mpv_resume deprecatedwm42016-09-161-5/+1
| | | | | | | They're useless, and I have no idea what they're actually supposed to do (wrt. pending input processing changes). Also remove their implicit uses from the IPC handlers.
* client API: remove SIGPIPE overriding codewm42016-09-151-0/+6
| | | | | | | This workaround prevented that libmpv users could accidentally crash when the SIGPIPE signal was triggered by FFmpeg's OpenSSL/GnuTLS usage. But it also modifies the global signal handler state, so remove it now that this workaround is not required anymore.
* osdep/io: introduce mp_flush_wakeup_pipe()Rostislav Pehlivanov2016-07-301-2/+1
| | | | Makes a fairly common occurence with wakeup_pipes easier to handle.
* build: silence -Wunused-resultNiklas Haas2016-06-071-2/+2
| | | | | | | | For clang, it's enough to just put (void) around usages we are intentionally ignoring the result of. Since GCC does not seem to want to respect this decision, we are forced to disable the warning globally.
* ipc: add Windows implementation with named pipesJames Ross-Gowan2016-03-231-0/+422
This implements the JSON IPC protocol with named pipes, which are probably the closest Windows equivalent to Unix domain sockets in terms of functionality. Like with Unix sockets, this will allow mpv to listen for IPC connections and handle multiple IPC clients at once. A few cross platform libraries and frameworks (Qt, node.js) use named pipes for IPC on Windows and Unix sockets on Linux and Unix, so hopefully this will ease the creation of portable JSON IPC clients. Unlike the Unix implementation, this doesn't share code with --input-file, meaning --input-file on Windows won't understand JSON commands (yet.) Sharing code and removing the separate implementation in pipe-win32.c is definitely a possible future improvement.