Lines Matching refs:a
4 Wait a minute? Why are we on threads? Aren't event loops supposed to be **the
10 calls. libuv also uses threads to allow you, the application, to perform a task
11 asynchronously that is actually blocking, by spawning a thread and collecting
18 A notable aspect of libuv's thread facilities is that it is a self contained
22 :ref:`first example <thread-create-example>`, don't even require a running
35 There isn't much here, you just start a thread using ``uv_thread_create()`` and
53 the thread, the last parameter is a ``void *`` argument which can be used to pass
54 custom parameters to the thread. The function ``hare`` will now run in a separate
64 Unlike ``pthread_join()`` which allows the target thread to pass back a value to
65 the calling thread using a second parameter, ``uv_thread_join()`` does not. To
78 The mutex functions are a **direct** map to the pthread equivalents.
101 The default BSD mutex implementation will raise an error if a thread which has
102 locked a mutex attempts to lock it again. For example, a construct like::
121 Read-write locks are a more granular access mechanism. Two readers can access
123 held by a reader. A reader or writer may not acquire a lock when a writer is
124 holding it. Read-write locks are frequently used in databases. Here is a toy
136 readers get a chance again.
151 In addition, libuv provides a convenience function ``uv_once()``. Multiple
152 threads can attempt to call ``uv_once()`` with a given guard and a function
183 libuv v0.11.11 onwards also added a ``uv_key_t`` struct and api_ for
191 ``uv_queue_work()`` is a convenience function that allows an application to run
192 a task in a separate thread, and have a callback that is triggered when the
197 when performing I/O or is a serious CPU hog*, because this means that the loop
200 However, a lot of existing code out there features blocking functions (for example
201 a routine which performs I/O under the hood) to be used with threads if you
204 own system of running the task in a separate thread. libuv just provides
205 a convenient abstraction for this.
207 Here is a simple example inspired by `node.js is cancer`_. We are going to
208 calculate fibonacci numbers, sleeping a bit along the way, but run it in
209 a separate thread so that the blocking and CPU bound task does not prevent the
219 run in a separate thread. The ``uv_work_t`` structure is the clue. You can pass
233 The thread function will be launched in a separate thread, passed the
238 For writing wrappers to blocking libraries, a common :ref:`pattern <baton>`
239 is to use a baton to exchange data.
243 that *are yet to be started* can be cancelled. If a task has *already started
247 termination. For example, a music player may queue up multiple directories to
252 up a signal handler for termination.
286 A well designed program would have a way to terminate long running workers
287 that have already started executing. Such a worker could periodically check
288 for a variable that only the main process sets to signal termination.
297 a separate thread (perhaps using ``uv_queue_work``) but want to notify progress
298 to the main thread. This is a simple example of having a download manager
311 with the async watcher whenever it receives a message.
322 or more calls, and libuv hasn't had a chance to run the callback yet, it
344 The callback is a standard libuv pattern, extracting the data from the watcher.
358 a mutex or rwlock to ensure accesses are performed in the right order.
362 mutexes and rwlocks **DO NOT** work inside a signal handler, whereas
367 node.js, a v8 engine instance, contexts and its objects are bound to the thread
370 which binds a third party library. It may go something like this:
372 1. In node, the third party library is set up with a JavaScript callback to be
387 3. The actual work being done in a separate thread wants to invoke the progress
