diff options
author | Hans de Goede <hdegoede@redhat.com> | 2011-08-18 07:29:15 -0700 |
---|---|---|
committer | Hans de Goede <hdegoede@redhat.com> | 2011-08-24 14:10:36 +0200 |
commit | 09a3698650891ef51fffb3690e9cc97e5555d91f (patch) | |
tree | 2efcbc1c4329cf37ea266b465f95afbeddd2c9b7 /README.multi-thread | |
parent | 4fbe701ae6ae2ef5a08d75793f39e0e085bb74d4 (diff) |
libusbredir*: Add (limited) multi-threading support
Diffstat (limited to 'README.multi-thread')
-rw-r--r-- | README.multi-thread | 73 |
1 files changed, 73 insertions, 0 deletions
diff --git a/README.multi-thread b/README.multi-thread new file mode 100644 index 0000000..b7fafd1 --- /dev/null +++ b/README.multi-thread @@ -0,0 +1,73 @@ +libusbredirparser and libusbredirhost are *not* 100% thread-safe. They allow +usage from multiple threads, but with limitations. + +The intended usage of the multi-threading support for libusbredirparser is to +have one reader thread and allow writes / packet sends from multiple threads +(including the reader thread). It is up to the app to deal with flushing +writes by calling do_write itself. do_write may be called from multiple +threads, libusbredirparser will serialize any calls to the write callback. + +The intended usage of the multi-threading support for libusbredirhost is to +have one reader thread, one thread calling libusb's handle_events function +and optionally also a separate writer thread. + +The above translates to some functions only allowing one caller at a time, +while others allow multiple callers, see below for a detailed overview. + +In order to enable the multi-thread support in libusbredir* the app +must provide a number of locking callback functions, by calling the +libusbredir*_set_locking_funcs function, ie: + +int usbredirparser_set_locking_funcs(struct usbredirparser *parser, + usbredirparser_alloc_lock alloc_lock_func, + usbredirparser_lock lock_func, + usbredirparser_unlock unlock_func, + usbredirparser_free_lock free_lock_func); + +The app should call usbredirparser_set_locking_funcs immediately after +usbredirparser_init, or call usbredirhost_set_locking_funcs immediately after +usbredirhost_open. The app should not use libusbredir* from multiple threads +in any way until this is done. + +Note this function will immediately call the alloc_lock_func a number of times, +and it will fail if this functions returns NULL at any time. It returns 0 on +success and -1 on error. If your alloc_lock_func cannot fail there is no +need to check the return value of this function. + +Overview of per function multi-thread safeness +---------------------------------------------- + +usbredirparser: +-Only one caller allowed at a time: + usbredirparser_create + usbredirparser_init + usbredirparser_destroy + usbredirparser_set_locking_funcs + usbredirparser_do_read + +-Multiple callers allowed: + usbredirparser_get_peer_caps (1) + usbredirparser_peer_has_cap (1) + usbredirparser_has_data_to_write + usbredirparser_do_write + usbredirparser_free_write_buffer + usbredirparser_free_packet_data + usbredirparser_send_* + +usbredirhost: +-Only one caller allowed at a time: + usbredirhost_open + usbredirhost_close + usbredirhost_set_locking_funcs + usbredirhost_read_guest_data + +-Multiple callers allowed: + usbredirhost_has_data_to_write + usbredirhost_write_guest_data + usbredirhost_free_write_buffer + libusb_handle_events (2) + +(1) These only return the actual peer caps after the initial hello message + has been read. + +(2) libusb is thread safe itself, thus allowing multiple callers. |