#
24d1d080 |
| 14-Jun-2023 |
Trevor Norris |
src: don't run timers if loop is stopped/unref'd (#4048) The initial run of timers shouldn't happen if uv_stop() has been run before uv_run() was called, and for backwards compatibility
src: don't run timers if loop is stopped/unref'd (#4048) The initial run of timers shouldn't happen if uv_stop() has been run before uv_run() was called, and for backwards compatibility they also shouldn't run if they have been unref'd before calling uv_run().
show more ...
|
#
1b01b786 |
| 24-May-2023 |
Ben Noordhuis |
unix,win: replace QUEUE with struct uv__queue (#4022) Recent versions of gcc have started emitting warnings about the liberal type casting inside the QUEUE macros. Although the warnings
unix,win: replace QUEUE with struct uv__queue (#4022) Recent versions of gcc have started emitting warnings about the liberal type casting inside the QUEUE macros. Although the warnings are false positives, let's use them as the impetus to switch to a type-safer and arguably cleaner approach. Fixes: https://github.com/libuv/libuv/issues/4019
show more ...
|
#
e02642cf |
| 17-Apr-2023 |
Trevor Norris |
src: fix events/events_waiting metrics counter (#3957) The worker pool calls all callbacks locally within the queue. So the value of nevents doesn't properly reflect that case. Increase
src: fix events/events_waiting metrics counter (#3957) The worker pool calls all callbacks locally within the queue. So the value of nevents doesn't properly reflect that case. Increase the number of events directly from the worker pool's callback to correct this. In order to properly determine if the events_waiting counter needs to be incremented, store the timeout value at the time the event provider was called.
show more ...
|
#
66009549 |
| 20-Mar-2023 |
Trevor Norris |
win,unix: change execution order of timers (#3927) The maximum number of times timers should run when uv_run() is called with UV_RUN_ONCE and UV_RUN_NOWAIT is 1. Do that by conditionally
win,unix: change execution order of timers (#3927) The maximum number of times timers should run when uv_run() is called with UV_RUN_ONCE and UV_RUN_NOWAIT is 1. Do that by conditionally calling timers before entering the while loop when called with UV_RUN_DEFAULT. The reason to always run timers at the end of the while loop, instead of at the beginning, is to help enforce the conceptual event loop model. Which starts when entering the event provider (e.g. calling poll). Other than only allowing timers to be processed once per uv_run() execution, the only other noticeable change this will show is if all the following are true: * uv_run() is called with UV_RUN_NOWAIT or UV_RUN_ONCE. * An event is waiting to be received when poll is called. * Execution time between the call to uv_timer_start() and entering the while loop is longer than the timeout. If all these are true, then timers that would have executed before entering the event provider will now be executed afterward. Fixes: https://github.com/libuv/libuv/issues/3686 Co-authored-by: Momtchil Momtchev <momtchil@momtchev.com>
show more ...
|
#
e1415860 |
| 11-Nov-2022 |
Trevor Norris |
src: add new metrics APIs (#3749) The following metrics are now always recorded and available via the new uv_metrics_info() API. * loop_count: Number of event loop iterations.
src: add new metrics APIs (#3749) The following metrics are now always recorded and available via the new uv_metrics_info() API. * loop_count: Number of event loop iterations. * events: Total number of events processed by the event handler. * events_waiting: Total number of events waiting in the event queue when the event provider request was made. Benchmarking has shown no noticeable impact recording these metrics. PR-URL: https://github.com/libuv/libuv/pull/3749
show more ...
|
#
2b4b293e |
| 04-Nov-2022 |
Saúl Ibarra Corretgé |
win,tcp,udp: remove "active streams" optimization It has been disabled for 11 years, I guess it should remain that way.
|
#
ee3718dd |
| 13-May-2022 |
Jameson Nash |
loop: better align order-of-events behavior between platforms (#3598) Previously, Windows would always defer event processing to the loop after they were received. This could cause confu
loop: better align order-of-events behavior between platforms (#3598) Previously, Windows would always defer event processing to the loop after they were received. This could cause confusion for users who were using prepare and idle callbacks, as seen from this bug in nodejs[^1] and this discussion in libuv[^2], and even some discrepancies in the libuv tests too[^3]. [^1]: https://github.com/nodejs/node/pull/42340 [^2]: https://github.com/libuv/libuv/discussions/3550 [^3]: See change to test-spawn.c in this PR So rather than declare those usages to be wrong, we change libuv to meet those users expectations. Replaces: https://github.com/libuv/libuv/pull/3585
show more ...
|
#
1fe609ea |
| 06-Apr-2022 |
Ben Noordhuis |
unix,win: fix UV_RUN_ONCE + uv_idle_stop loop hang (#3590) Wrong accounting of idle handles in uv_run() made it sleep when there was nothing left to do. Do a non-blocking poll for I/O in
unix,win: fix UV_RUN_ONCE + uv_idle_stop loop hang (#3590) Wrong accounting of idle handles in uv_run() made it sleep when there was nothing left to do. Do a non-blocking poll for I/O instead.
show more ...
|
#
d54c92e3 |
| 15-Feb-2022 |
Jameson Nash |
win: fix style nits [NFC] (#3474) Internal functions usually have a uv__ prefix.
|
#
02094664 |
| 14-Feb-2022 |
twosee |
win,loop: add missing uv_update_time (#3175) Time of loop should be updated after the IOCP wait.
|
#
939a0563 |
| 13-Feb-2022 |
Jameson Nash |
loop: add pending work to loop-alive check (#3466) Pending work may be either (on any platform) pending_queue callbacks or (on unix) watcher_queue handles to add to the io poll object.
loop: add pending work to loop-alive check (#3466) Pending work may be either (on any platform) pending_queue callbacks or (on unix) watcher_queue handles to add to the io poll object. Previously, we might have gotten somewhat stuck if the user caused an event to be added to one of these in the idle or prepare callbacks, or was embedding libuv. Refs: https://github.com/libuv/libuv/pull/3234 Refs: https://github.com/libuv/libuv/issues/3101 Refs: https://github.com/libuv/libuv/pull/3308
show more ...
|
Revision tags: v1.41.0, v1.40.0, v1.39.0, v1.38.1, v1.38.0, v1.37.0, v1.36.0 |
|
#
e8effd45 |
| 26-Mar-2020 |
Trevor Norris |
core: add API to measure event loop idle time The API addition `uv_metrics_idle_time()` is a thread safe call that allows the user to retrieve the amount of time the event loop has spent
core: add API to measure event loop idle time The API addition `uv_metrics_idle_time()` is a thread safe call that allows the user to retrieve the amount of time the event loop has spent in the kernel's event provider (i.e. poll). It was done this way to allow retrieving this value without needing to interrupt the execution of the event loop. This option can be enabled by passing `UV_METRICS_IDLE_TIME` to `uv_loop_configure()`. One important aspect of this change is, when enabled, to always first call the event provider with a `timeout == 0`. This allows libuv to know whether any events were waiting in the event queue when the event provider was called. The importance of this is because libuv is tracking the amount of "idle time", not "poll time". Thus the provider entry time is not recorded when `timeout == 0` (the event provider never idles in this case). While this does add a small amount of overhead, when enabled, but the overhead decreases when the event loop has a heavier load. This is because poll events will be waiting when the event provider is called. Thus never actually recording the provider entry time. Checking if `uv_loop_t` is configured with `UV_METRICS_IDLE_TIME` always happens in `uv__metrics_set_provider_entry_time()` and `uv__metrics_update_idle_time()`. Making the conditional logic wrapping each call simpler and allows for instrumentation to always hook into those two function calls. Rather than placing the fields directly on `uv__loop_internal_fields_t` add the struct `uv__loop_metrics_t` as a location for future metrics API additions. Tests and additional documentation has been included. PR-URL: https://github.com/libuv/libuv/pull/2725 Reviewed-By: Fedor Indutny <fedor.indutny@gmail.com> Reviewed-By: Santiago Gimeno <santiago.gimeno@gmail.com> Reviewed-By: Jameson Nash <vtjnash@gmail.com>
show more ...
|
#
70bbc093 |
| 18-Mar-2020 |
Trevor Norris |
include: add internal fields struct to uv_loop_t Add struct `uv__loop_internal_fields_t` as a location for future additions to `uv_loop_t` while also maintaining v1.x compatibility.
include: add internal fields struct to uv_loop_t Add struct `uv__loop_internal_fields_t` as a location for future additions to `uv_loop_t` while also maintaining v1.x compatibility. Currently `uv__loop_internal_fields_t` only contains the `flags` field. The reason for adding the `flags` field is because the same field was never added to `UV_LOOP_PRIVATE_FIELDS` in Windows as it was in Unix. The idea for creating a struct and attaching it to `uv_loop_t` for future API enhancements was taken from a comment by bnoordhuis in: https://github.com/libuv/libuv/issues/2506#issuecomment-540050665 Also add `internal_fields` to `uv_loop_t` to store the pointer to `uv__loop_internal_fields_t`. This naming makes more sense than just using `active_reqs.unused[1]`. To maintain ABI compatibility, shrink the `unused` array. PR-URL: https://github.com/libuv/libuv/pull/2725 Reviewed-By: Fedor Indutny <fedor.indutny@gmail.com> Reviewed-By: Santiago Gimeno <santiago.gimeno@gmail.com> Reviewed-By: Jameson Nash <vtjnash@gmail.com>
show more ...
|
#
aa93eb25 |
| 22-Apr-2020 |
Colin Finck |
win: remove dep on GetQueuedCompletionStatusEx Libuv already works without that API since commit 153ea114ff but still had it as a hard requirement in the import table. This code uses the
win: remove dep on GetQueuedCompletionStatusEx Libuv already works without that API since commit 153ea114ff but still had it as a hard requirement in the import table. This code uses the `pGetQueuedCompletionStatusEx` function pointer instead, hence it also works on systems that don't export `GetQueuedCompletionStatusEx`. This simple fix improves compatibility of libuv with ReactOS and Windows XP (latter using Vista+ compatibility libraries like https://github.com/MyTDT-Mysoft/DllCompat) PR-URL: https://github.com/libuv/libuv/pull/2800 Reviewed-By: Bartosz Sosnowski <bartosz@janeasystems.com> Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
show more ...
|
Revision tags: v1.35.0, v1.34.2, v1.34.1 |
|
#
623aa05a |
| 09-Jan-2020 |
Jameson Nash |
win: remove bad assert in uv_loop_close This assert was stronger than necessary (we assert the actual condition later in this function). And it's vulnerable to a race condition occur
win: remove bad assert in uv_loop_close This assert was stronger than necessary (we assert the actual condition later in this function). And it's vulnerable to a race condition occurring in uv__work_done where we drain the work queue but still have a stale message on this object. Fixes: https://github.com/libuv/libuv/issues/2610 PR-URL: https://github.com/libuv/libuv/pull/2615 Reviewed-By: Anna Henningsen <anna@addaleax.net> Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com> Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
show more ...
|
Revision tags: v1.34.0, v1.33.1, v1.33.0, v1.32.0, v1.31.0, v1.30.1, v1.30.0, v1.29.1, v1.29.0 |
|
#
2c279504 |
| 09-May-2019 |
João Reis |
win: add UV_FS_O_FILEMAP Reading and writing files using a memory file mapping can be significantly faster on Windows. PR-URL: https://github.com/libuv/libuv/pull/2295 Revie
win: add UV_FS_O_FILEMAP Reading and writing files using a memory file mapping can be significantly faster on Windows. PR-URL: https://github.com/libuv/libuv/pull/2295 Reviewed-By: Bartosz Sosnowski <bartosz@janeasystems.com>
show more ...
|
#
c905e0be |
| 02-Jul-2019 |
Javier Blazquez |
win,fs: don't modify global file translation mode The MSVC runtime provides a global variable that can be used to set the default file translation mode so that file open calls don't need
win,fs: don't modify global file translation mode The MSVC runtime provides a global variable that can be used to set the default file translation mode so that file open calls don't need to explicitly specify that mode. libuv was changing that global mode to binary from its default of text. However, libuv doesn't actually need to do that anymore, and the application may not want the default changed under it. This change stops libuv from modifying that global mode. PR-URL: https://github.com/libuv/libuv/pull/2324 Reviewed-By: Bartosz Sosnowski <bartosz@janeasystems.com> Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl> Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
show more ...
|
Revision tags: v1.28.0, v1.27.0, v1.26.0, v1.25.0, v1.24.1, v1.24.0, v1.23.2, v1.23.1, v1.23.0, v1.22.0, v1.21.0 |
|
#
d16897c4 |
| 31-May-2018 |
Santiago Gimeno |
unix: refactor getsockname/getpeername methods PR-URL: https://github.com/libuv/libuv/pull/1872 Backport-PR-URL: https://github.com/libuv/libuv/pull/2217 Reviewed-By: Saúl Ibarra Cor
unix: refactor getsockname/getpeername methods PR-URL: https://github.com/libuv/libuv/pull/1872 Backport-PR-URL: https://github.com/libuv/libuv/pull/2217 Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com> Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
show more ...
|
#
153ea114 |
| 28-Aug-2018 |
Jameson Nash |
Partially revert "win,code: remove GetQueuedCompletionStatus-based poller" This reverts commit fd8d212a802a1f2b2aa29bfca93b72f0875f3c2d, and thereby restores partial support for using li
Partially revert "win,code: remove GetQueuedCompletionStatus-based poller" This reverts commit fd8d212a802a1f2b2aa29bfca93b72f0875f3c2d, and thereby restores partial support for using libuv under Wine (which does not implement GetQueuedCompletionStatusEx). PR-URL: https://github.com/libuv/libuv/pull/1963 Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl> Reviewed-By: Bert Belder <bertbelder@gmail.com>
show more ...
|
#
7284adfa |
| 12-Aug-2018 |
cjihrig |
win: return UV_ENOMEM from uv_loop_init() This commit sets the error returned by uv_loop_init() to UV_ENOMEM in the case of a failed timer heap malloc. PR-URL: https://github.co
win: return UV_ENOMEM from uv_loop_init() This commit sets the error returned by uv_loop_init() to UV_ENOMEM in the case of a failed timer heap malloc. PR-URL: https://github.com/libuv/libuv/pull/1944 Reviewed-By: Santiago Gimeno <santiago.gimeno@gmail.com>
show more ...
|
#
619937c7 |
| 28-Jun-2018 |
Ben Noordhuis |
unix,win: merge handle flags Some long overdue refactoring that unifies more of the UNIX and Windows backends. PR-URL: https://github.com/libuv/libuv/pull/1904 Reviewed-By:
unix,win: merge handle flags Some long overdue refactoring that unifies more of the UNIX and Windows backends. PR-URL: https://github.com/libuv/libuv/pull/1904 Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
show more ...
|
#
95c5bf8d |
| 14-Jun-2018 |
Ben Noordhuis |
unix,win: merge timers implementation Merge src/unix/timer.c and src/win/timer.c into src/timer.c. This changes the Windows implementation from a binary tree to a binary heap for ge
unix,win: merge timers implementation Merge src/unix/timer.c and src/win/timer.c into src/timer.c. This changes the Windows implementation from a binary tree to a binary heap for generally better performance. PR-URL: https://github.com/libuv/libuv/pull/1882 Reviewed-By: Bartosz Sosnowski <bartosz@janeasystems.com> Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
show more ...
|
#
fd8d212a |
| 30-May-2018 |
Bert Belder |
win,code: remove GetQueuedCompletionStatus-based poller All Windows versions that libuv supports have GetQueuedCompletionStatusEx, so this fallback option is no longer needed. P
win,code: remove GetQueuedCompletionStatus-based poller All Windows versions that libuv supports have GetQueuedCompletionStatusEx, so this fallback option is no longer needed. PR-URL: https://github.com/libuv/libuv/pull/1858 Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Bartosz Sosnowski <bartosz@janeasystems.com>
show more ...
|
Revision tags: v1.20.3, v1.20.2, v1.20.1, v1.20.0, v1.19.2, v1.19.1, v1.19.0, v1.18.0, v1.17.0 |
|
#
88c2af0e |
| 14-Nov-2017 |
Jameson Nash |
req: revisions to uv_req_t handling - Remove the `active_reqs` queue, which is never used. There are more efficient per-stream queues that `libuv` uses whenever it needs this
req: revisions to uv_req_t handling - Remove the `active_reqs` queue, which is never used. There are more efficient per-stream queues that `libuv` uses whenever it needs this information, so duplicating it and managing it here seems like unnecessary extra space and work. - Unix `uv_loop_init` didn't explicitly initialize. `loop->active_handles` (although it did memset the whole struct to 0, so it wasn't wrong previously, just inconsistent). - Consolidate repeated code for `uv__has_active_reqs`. - Change `uv__loop_alive` to use the helper functions (mirroring the unix copy of the same function). - Initialize some more uv_stream_t fields in init, rather than waiting for the connection callback. This helps surface bugs in libuv or the caller better, since it ensures libuv doesn't see uninitialized memory if asked to look at these fields before it thinks the socket is connected. - Fixes what appears to be a double-counting of `handle->reqs_pending`, in the highly-unlikely event that the code wants to emulate IOCP, but `RegisterWaitForSingleObject` somehow managed to fail. PR-URL: https://github.com/libuv/libuv/pull/1746 Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl> Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Santiago Gimeno <santiago.gimeno@gmail.com>
show more ...
|
Revision tags: v1.16.1, v1.16.0, v1.15.0, v1.14.1, v1.14.0, v1.13.1, v1.13.0, v1.12.0 |
|
#
fd39cec4 |
| 27-Apr-2017 |
Jameson Nash |
build: add -Wstrict-prototypes Fixes: https://github.com/libuv/libuv/pull/1320 PR-URL: https://github.com/libuv/libuv/pull/1326 Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Revie
build: add -Wstrict-prototypes Fixes: https://github.com/libuv/libuv/pull/1320 PR-URL: https://github.com/libuv/libuv/pull/1326 Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Santiago Gimeno <santiago.gimeno@gmail.com>
show more ...
|