History log of /libuv/src/unix/loop.c (Results 1 – 25 of 65)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
(<<< Hide modified files)
(Show modified files >>>)
# 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 ...


# 42cc412c 01-Feb-2023 Jameson Nash

darwin,process: feed kevent the signal to reap children (#3893)

Since we are emulating this event, but are not using the pending_queue,
we need to make sure it is accounted for properly.

darwin,process: feed kevent the signal to reap children (#3893)

Since we are emulating this event, but are not using the pending_queue,
we need to make sure it is accounted for properly. Also DRY some of the
reset_timeout code here.

This was observed to cause a hang in certain rare cases, particularly on
M1 machines.

Do a bit of code cleanup too, since we do not need to initialize the
internal signal handling pipe if it will not be used.

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 ...


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 ...


# 55dede5b 07-May-2020 Anna Henningsen

unix: fix memory leak when uv_loop_init() fails

`uv_signal_init()` leads to the allocation of an IO watcher,
so if the loop initialization fails at a later point,
the `loop->watchers

unix: fix memory leak when uv_loop_init() fails

`uv_signal_init()` leads to the allocation of an IO watcher,
so if the loop initialization fails at a later point,
the `loop->watchers` list needs to be released.

PR-URL: https://github.com/libuv/libuv/pull/2837
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Santiago Gimeno <santiago.gimeno@gmail.com>

show more ...


Revision tags: v1.35.0, v1.34.2, v1.34.1, 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, 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
# 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 ...

Revision tags: v1.21.0, 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, v1.16.1, v1.16.0, v1.15.0, v1.14.1, v1.14.0
# 99ae3edf 22-Jul-2017 Saúl Ibarra Corretgé

core: move all include files except uv.h to uv/

This is a cherry-pick of commit d010030ad5 from the master branch.

Conflicts:
Makefile.am
include/uv.h

core: move all include files except uv.h to uv/

This is a cherry-pick of commit d010030ad5 from the master branch.

Conflicts:
Makefile.am
include/uv.h
include/uv/unix.h
libuv.nsi (deleted)
src/unix/pthread-barrier.c (deleted)

PR-URL: https://github.com/libuv/libuv/pull/1850
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>

show more ...

# 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 ...

# 44b7c710 21-Aug-2017 John Barboza

zos: reset epoll data after fork

Remove all the epoll file descriptors after a fork since they are
no longer valid. The uv__signal_global_once_init function needs to
be run after uv_

zos: reset epoll data after fork

Remove all the epoll file descriptors after a fork since they are
no longer valid. The uv__signal_global_once_init function needs to
be run after uv__platform_loop_init so that the epoll pthread_atfork
handlers get run first.

PR-URL: https://github.com/libuv/libuv/pull/1496
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>

show more ...

Revision tags: v1.13.1, v1.13.0, v1.12.0, v1.11.0, v1.10.2, v1.10.1, v1.10.0, v0.10.37, v1.9.1
# fd7ce57f 22-Apr-2016 Jason Madden

unix: make loops and watchers usable after fork()

Added the uv_loop_fork() API that must be called in a child process to
continue using an existing loop. Internally this calls a uv__io_f

unix: make loops and watchers usable after fork()

Added the uv_loop_fork() API that must be called in a child process to
continue using an existing loop. Internally this calls a uv__io_fork
function for each supported platform, similar to the way
uv__platform_loop_init works.

After this call, existing and new IO, async and signal watchers will
contiue working as before on all platforms, as will the
threadpool (although any threads it was using are of course gone).

On Linux and BSDs that use kqueue, existing and new fsevent watchers
will also continue to work as expected. On OS X, though, directory
fsevents will not be able to use the optimized CoreFoundation path if
they had already been used in the parent process, instead falling back
to the kqueue path used on other BSDs.

Existing fsevent watchers will not function on AIX or SunOS. This
could be relatively easily fixed by someone with AIX knowledge in the
future, but SunOS will require some additional work to keep track if
the watchers.

A new test file, test/test-fork.c, was added to contain fork-related
tests to verify functionality in the child process.

PR-URL: https://github.com/libuv/libuv/pull/846
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>

show more ...

# 5fc8aecd 14-Mar-2017 Ben Noordhuis

unix: simplify async watcher dispatch logic

Remove the unused `nevents` parameter from `uv__async_event()`
and remove the indirection of having a separate `uv__async`
type. There is

unix: simplify async watcher dispatch logic

Remove the unused `nevents` parameter from `uv__async_event()`
and remove the indirection of having a separate `uv__async`
type. There is only one instance per event loop these days.

This incidentally removes the `assert(n == sizeof(val))` in a
Linux-specific code path that some users seem to hit from time
to time. The cause is not well-understood and I've never been
able to reproduce it myself. Presumably libuv gets an EAGAIN
when trying to read from the eventfd but when and why that
happens is unclear.

Since the byte count is unused, removing the assert seems safe.
Worst case, libuv sometimes iterates over the async watcher list
when it doesn't have to.

Fixes: https://github.com/libuv/libuv/issues/1171
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Santiago Gimeno <santiago.gimeno@gmail.com>
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
Supersedes: https://github.com/libuv/libuv/pull/1214

show more ...

# ff0ae104 20-Jul-2016 Ben Noordhuis

unix: preserve loop->data across loop init/done

Libuv leaves loop->data unchanged in uv_loop_init() and uv_loop_done()
on Windows but it clobbered it on UNIX platforms. This commit fixe

unix: preserve loop->data across loop init/done

Libuv leaves loop->data unchanged in uv_loop_init() and uv_loop_done()
on Windows but it clobbered it on UNIX platforms. This commit fixes
that inconsistency.

PR-URL: https://github.com/libuv/libuv/pull/951
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>

show more ...

Revision tags: v1.9.0, v1.8.0, v1.7.5, v1.7.4, v1.7.3, v1.7.2, v1.7.1, v1.7.0
# 2a51b61e 20-Jun-2015 Willem Thiart

unix, win: make uv_loop_init return on error

Makes uv_loop_init return an error code instead of aborting.

Currently uv_loop_init aborts if there are insufficient resources
avail

unix, win: make uv_loop_init return on error

Makes uv_loop_init return an error code instead of aborting.

Currently uv_loop_init aborts if there are insufficient resources
available. As a user I want to be able to check the return code from
uv_loop_init and decide how I respond rather than having my process die.

PR-URL: https://github.com/libuv/libuv/pull/405
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>

show more ...

Revision tags: v1.6.1, v1.6.0
# bddd6a84 26-May-2015 Saúl Ibarra Corretgé

core: add ability to customize memory allocator

This patch is composed by the work done in
https://github.com/libuv/libuv/pull/231 and
https://github.com/libuv/libuv/pull/287 plus so

core: add ability to customize memory allocator

This patch is composed by the work done in
https://github.com/libuv/libuv/pull/231 and
https://github.com/libuv/libuv/pull/287 plus some changes by yours
truly.

Thanks @beevik and @mattsta for their work on this!

PR-URL: https://github.com/libuv/libuv/pull/368
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>

show more ...

Revision tags: v1.5.0
# 1f711e4d 29-Apr-2015 Saúl Ibarra Corretgé

Revert "memory: add uv_replace_allocator"

This reverts commit c272f1f1bc0bda625e6441d798c110b4064a6ce2.

The concept will come back to libuv, but it needs some more work.

# c272f1f1 26-Feb-2015 Brett Vickers

memory: add uv_replace_allocator

With uv_replace_allocator, it's possible to override the default
memory allocator's malloc and free calls with functions of the user's
choosing. This

memory: add uv_replace_allocator

With uv_replace_allocator, it's possible to override the default
memory allocator's malloc and free calls with functions of the user's
choosing. This allows libuv to interoperate with projects requiring a
custom memory allocator.

Internally, all calls to malloc and free have been replaced with
uv__malloc and uv__free, respectively. The uv__malloc and uv__free
functions call malloc and free unless they have been overridden by a
previous call to uv_replace_allocator.

As part of this change, the special aligned memory allocations
performed in src/win/fs-event.c have been replaced with standard
allocations. The 4-byte alignment being requested in this file was
unnecessary, since standard allocators already guarantee at least an
8-byte alignment.

PR-URL: https://github.com/libuv/libuv/pull/231
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>

show more ...

Revision tags: v0.10.36, v1.4.2, v0.10.35, v1.4.1, v0.10.34, v1.4.0, v1.3.0, v0.10.33
# 32747c75 20-Jan-2015 Andrius Bentkus

win,unix: move loop functions which have identical implementations

uv_default_loop, uv_loop_new, uv_loop_close, uv_loop_delete

PR-URL: https://github.com/libuv/libuv/pull/144
Re

win,unix: move loop functions which have identical implementations

uv_default_loop, uv_loop_new, uv_loop_close, uv_loop_delete

PR-URL: https://github.com/libuv/libuv/pull/144
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-by: Saúl Ibarra Corretgé <saghul@gmail.com>

show more ...

Revision tags: v1.2.1, v1.2.0, v0.10.32, v1.1.0, v0.10.31, v1.0.2, v0.10.30
# a6f2a4f8 05-Dec-2014 Ben Noordhuis

Merge branch 'v0.10' into v1.x

Conflicts:
AUTHORS
ChangeLog
README.md
config-unix.mk
include/uv.h
src/unix/internal.h

Merge branch 'v0.10' into v1.x

Conflicts:
AUTHORS
ChangeLog
README.md
config-unix.mk
include/uv.h
src/unix/internal.h
src/unix/kqueue.c
src/unix/linux-core.c
src/unix/stream.c
src/uv-common.c
src/uv-common.h
src/version.c
test/test-osx-select.c

show more ...


# 9da5fd44 27-Nov-2014 Ben Noordhuis

unix, windows: add uv_loop_configure() function

The only supported option right now is UV_LOOP_BLOCK_SIGNAL, which only
supports the SIGPROF signal and only on UNIX platforms. So yes, i

unix, windows: add uv_loop_configure() function

The only supported option right now is UV_LOOP_BLOCK_SIGNAL, which only
supports the SIGPROF signal and only on UNIX platforms. So yes, it is
kind of limited right now. But everything has to start somewhere.

Refs strongloop/strong-agent#3 and strongloop-internal/scrum-cs#37.

PR-URL: https://github.com/libuv/libuv/pull/15
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>

show more ...

Revision tags: v1.0.1, v1.0.0, v0.10.29, v1.0.0-rc2, v1.0.0-rc1, v0.11.29, v0.11.28, v0.11.27, v0.10.28, v0.11.26
# 2d5eaea1 05-May-2014 Saúl Ibarra Corretgé

unix: simplify how process handle queue is managed

# 2cd91f97 01-Aug-2014 John Firebaugh

unix, windows: move uv_loop_close out of assert

Closes #1387

Revision tags: v0.10.27, v0.11.25, v0.11.24, v0.11.23, v0.10.26, v0.11.22, v0.11.21
# 2611ef43 27-Feb-2014 Saúl Ibarra Corretgé

unix, windows: add assertion in uv_loop_delete

Revision tags: v0.11.20, v0.10.25
# 787f5fff 17-Feb-2014 Saúl Ibarra Corretgé

unix, windows: add uv_loop_init and uv_loop_close

These functions supersede uv_loop_new and uv_loop_delete.
uv_loop_init initialized a user allocated loop and uv_loop_close
removes a

unix, windows: add uv_loop_init and uv_loop_close

These functions supersede uv_loop_new and uv_loop_delete.
uv_loop_init initialized a user allocated loop and uv_loop_close
removes all associated resources a loop uses after it has finished
execution.

uv_loop_new and uv_loop_delete are now deprecated.

show more ...

Revision tags: v0.11.19, v0.10.24, v0.11.18, v0.10.23, v0.10.22, v0.11.17, v0.10.21, v0.11.16, v0.10.20, v0.11.15, v0.10.19, v0.11.14, v0.10.18, v0.10.17
# f17c535b 12-Sep-2013 Ben Noordhuis

unix: use a heap for timers

Replace the red-black tree with a heap. The most common operation that
libuv performs on timers is looking up the first timer to expire. With
a red-blac

unix: use a heap for timers

Replace the red-black tree with a heap. The most common operation that
libuv performs on timers is looking up the first timer to expire. With
a red-black tree, that operation is O(log n). With a heap, it's O(1).

show more ...

123