zos: correctly get cpu model in uv_cpu_info() (#4136)

The previous implementation using si11v1cpcmodel did not return a valid
cpu model on z/OS. So use PCCA instead to correctly get the

zos: correctly get cpu model in uv_cpu_info() (#4136)

The previous implementation using si11v1cpcmodel did not return a valid
cpu model on z/OS. So use PCCA instead to correctly get the cpu model.

Co-authored-by: Wayne Zhang <shuowang.zhang@ibm.com>
Co-authored-by: Gaby Baghdadi <baghdadi@ca.ibm.com>
Co-authored-by: Jonathan Lai <jonathan.lai@ibm.com>
Fixes: https://github.com/libuv/libuv/issues/4102

show more ...

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

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

unix,win: add uv_get_available_memory() (#3754)

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

zos: delay signal handling until after normal i/o (#3643)

Port the changes made to AIX and other unix systems in #611 to z/OS.

Defers the signal watcher that is used for process man

zos: delay signal handling until after normal i/o (#3643)

Port the changes made to AIX and other unix systems in #611 to z/OS.

Defers the signal watcher that is used for process management until
after the dispatch of regular i/o watchers.

Refs: https://github.com/libuv/libuv/pull/611
Co-authored-by: Igor Todorovski <itodorov@ca.ibm.com>

show more ...

zos: fix early exit of epoll_wait() (#3653)

This fixes an early exit bug in z/OS implementation of epoll_wait(),
resulting in some file events not being correctly captured.

The

zos: fix early exit of epoll_wait() (#3653)

This fixes an early exit bug in z/OS implementation of epoll_wait(),
resulting in some file events not being correctly captured.

The problem is that reventcount should only be incremented by 1, because
_NFDS counts as 1 even for fds with multiple revents set.

Also makes a few minor improvements to remove redundant checks.

Co-authored-by: Igor Todorovski <itodorov@ca.ibm.com>

show more ...

zos: improve memory management of ip addresses (#3640 3/3)

Fixes an issue where under certain conditions, dynamically allocated
ip addresses, strings, and buffers were either leaking mem

zos: improve memory management of ip addresses (#3640 3/3)

Fixes an issue where under certain conditions, dynamically allocated
ip addresses, strings, and buffers were either leaking memory, being
incorrectly freed, or not performing error checks.

Also fixes an issue where the uv_interface_address_t struct was not
correctly initialized to 0, so use calloc() instead of malloc().

Co-authored-by: Igor Todorovski <itodorov@ca.ibm.com>

show more ...

zos: add uv_interface_addresses() netmask support (#3640 2/3)

Use SIOCGIFNETMASK ioctl to retrieve the netmask for IPv4. However, this
approach is not supported for IPv6.

For IP

zos: add uv_interface_addresses() netmask support (#3640 2/3)

Use SIOCGIFNETMASK ioctl to retrieve the netmask for IPv4. However, this
approach is not supported for IPv6.

For IPv6 netmask, z/OS currently only provides the prefix length through
the __nif6e_prefixlen in __net_ifconf6entry_t struct, but this can be
used to calculate the IPv6 netmask similar to android implementation.

Co-authored-by: Igor Todorovski <itodorov@ca.ibm.com>

show more ...

zos: correctly format interface addresses names (#3640 1/3)

On z/OS, the interface address name contains EBCDIC and may be padded
with whitespaces. The whitespace padding needs to be tri

zos: correctly format interface addresses names (#3640 1/3)

On z/OS, the interface address name contains EBCDIC and may be padded
with whitespaces. The whitespace padding needs to be trimmed, and the
interface address name needs to be converted from EBCDIC to ASCII.

Co-authored-by: John Barboza <jbarboza@ca.ibm.com>
Co-authored-by: Igor Todorovski <itodorov@ca.ibm.com>

show more ...

zos: avoid fs event callbacks after uv_close() (#3620)

On z/OS, fs events are implemented by registering file interest. When
closing a fs event handle, it's possible that a change notifi

zos: avoid fs event callbacks after uv_close() (#3620)

On z/OS, fs events are implemented by registering file interest. When
closing a fs event handle, it's possible that a change notification has
already been generated. In that case, the attempt to unregister file
interest will fail with EALREADY. This will result in the fs event being
delivered even though the handle is closing, which should not happen.

Fixes: https://github.com/libuv/libuv/issues/3601

show more ...

uv: register __rfim_event 156 as UV_RENAME (#3540 3/3)

When the watched file is moved or removed, or an editor (e.g. vim)
renames then creates the file, the __rfim_event 156 occurs. This

uv: register __rfim_event 156 as UV_RENAME (#3540 3/3)

When the watched file is moved or removed, or an editor (e.g. vim)
renames then creates the file, the __rfim_event 156 occurs. This is an
undocumented event that should not happen, but register it as UV_RENAME
for now since it is functionally equivalent.

Co-authored-by: Gaby Baghdadi <baghdadi@ca.ibm.com>

show more ...

uv: register UV_RENAME event for _RFIM_UNLINK (#3540 2/3)

`rename()` can be used to rename a file path via _RFIM_UNLINK. So
register it as a UV_RENAME event.

Co-authored-by: Igo

uv: register UV_RENAME event for _RFIM_UNLINK (#3540 2/3)

`rename()` can be used to rename a file path via _RFIM_UNLINK. So
register it as a UV_RENAME event.

Co-authored-by: Igor Todorovski <itodorov@ca.ibm.com>

show more ...

uv: re-register interest in a file after change (#3540 1/3)

The file is implicitly unregistered when the change notification is
sent, only one notification is sent per registration. So w

uv: re-register interest in a file after change (#3540 1/3)

The file is implicitly unregistered when the change notification is
sent, only one notification is sent per registration. So we need to
re-register interest in a file after each change notification we
receive.

Co-authored-by: Gaby Baghdadi <baghdadi@ca.ibm.com>

show more ...

zos: use CVTRLSTG to get total memory accurately

The previous implementation using rcepool would return a value that is
slightly off from the true value of the system's total memory. So

zos: use CVTRLSTG to get total memory accurately

The previous implementation using rcepool would return a value that is
slightly off from the true value of the system's total memory. So use
CVTRLSTG to get total memory instead, which is more accurate. For more
information on CVTRLSTG, see MVS Data Areas Volumes 1 and 3.

Co-authored-by: Gaby Baghdadi <49249542+gabylb@users.noreply.github.com>
PR-URL: https://github.com/libuv/libuv/pull/3141
Reviewed-By: Richard Lau <rlau@redhat.com>

show more ...

zos: fix uv_get_free_memory()

The previous implementation of `uv_get_free_memory()` on z/OS return
incorrect values. This is because the rceafc field being dereferenced
for the memor

zos: fix uv_get_free_memory()

The previous implementation of `uv_get_free_memory()` on z/OS return
incorrect values. This is because the rceafc field being dereferenced
for the memory values needs to be treated as unsigned int.

Co-authored-by: Igor Todorovski <itodorov@ca.ibm.com>
Co-authored-by: Alex Yung <alex.yung@ibm.com>
Co-authored-by: CW Cheung <ccw.280231@ca.ibm.com>
PR-URL: https://github.com/libuv/libuv/pull/3141
Reviewed-By: Richard Lau <rlau@redhat.com>

show more ...

zos: implement uv_get_constrained_memory()

Implementation is based on RLIMIT_MEMLIMIT.

Co-authored-by: Igor Todorovski <itodorov@ca.ibm.com>
PR-URL: https://github.com/libuv/lib

zos: implement uv_get_constrained_memory()

Implementation is based on RLIMIT_MEMLIMIT.

Co-authored-by: Igor Todorovski <itodorov@ca.ibm.com>
PR-URL: https://github.com/libuv/libuv/pull/3133
Reviewed-By: Richard Lau <rlau@redhat.com>

show more ...

zos: use custom proctitle implementation

ZOSLIB uses `argv[0]` to determine the exepath. So it is necessary to
use an implementation of proctitle that does not modify `argv[0]`. Since

zos: use custom proctitle implementation

ZOSLIB uses `argv[0]` to determine the exepath. So it is necessary to
use an implementation of proctitle that does not modify `argv[0]`. Since
there is currently no support for process titles on z/OS, the custom
proctitle implementation simply stores the desired title in memory.

This resolves failure in tests `get_currentexe` and `process_title` on
z/OS.

PR-URL: https://github.com/libuv/libuv/pull/3060
Reviewed-By: Richard Lau <rlau@redhat.com>

show more ...

zos: treat __rfim_utok as binary

`__rfim_utok` is treated as text when it should be treated as binary
while running in ASCII mode, resulting in an unwanted autoconversion. So
undo th

zos: treat __rfim_utok as binary

`__rfim_utok` is treated as text when it should be treated as binary
while running in ASCII mode, resulting in an unwanted autoconversion. So
undo the conversion explicitly.

PR-URL: https://github.com/libuv/libuv/pull/3060
Reviewed-By: Richard Lau <rlau@redhat.com>

show more ...

zos: use __getargv() from zoslib to get exe path

The ZOSLIB implementation adds support for ASCII code page.

PR-URL: https://github.com/libuv/libuv/pull/3060
Reviewed-By: Richar

zos: use __getargv() from zoslib to get exe path

The ZOSLIB implementation adds support for ASCII code page.

PR-URL: https://github.com/libuv/libuv/pull/3060
Reviewed-By: Richard Lau <rlau@redhat.com>

show more ...

aix: protect uv_exepath() from uv_set_process_title()

Store a copy of the original argv[0] to protect `uv_exepath()`
against `uv_set_process_title()` changing the value of argv[0].

aix: protect uv_exepath() from uv_set_process_title()

Store a copy of the original argv[0] to protect `uv_exepath()`
against `uv_set_process_title()` changing the value of argv[0].

Extract common code for finding a program on the current PATH.

Fixes: https://github.com/libuv/libuv/issues/2674
PR-URL: https://github.com/libuv/libuv/pull/2677
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Jameson Nash <vtjnash@gmail.com>

show more ...

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

zos: fix potential event loop stall

This is a port of 70002c80 to z/OS to fix the same potential issue that
could effectively enter an infinite loop (but not a busy loop) under
certa

zos: fix potential event loop stall

This is a port of 70002c80 to z/OS to fix the same potential issue that
could effectively enter an infinite loop (but not a busy loop) under
certain conditions when polling for events.

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

zos: explicitly mark message queue events

The os390 epoll_wait implementation uses poll() to detect events in
both file descriptors and the message queue used for file system
events.

zos: explicitly mark message queue events

The os390 epoll_wait implementation uses poll() to detect events in
both file descriptors and the message queue used for file system
events. The only message queue ID is always placed at the end of the
array passed to the poll() call. When the poll() call returns all FDs
and the message queue are checked for events by iterating through that
array. In order to distinguish the message queue from the FDs its ID
value is compared with the only message queue ID we have and if it
matches the message queue handler function is called.

When the message queue ID is relatively small, it may have the same
value as the value of one of the file descriptors. If this happens,
the message queue handler is called for the matching file descriptor,
and this call fails. The file descriptor ends up being unhandled and
this makes the next poll() call to return immediately. Eventually this
will happen again and again, leading to an infinite busy loop and high
CPU usage.

To prevent the incorrect interpretation of file descriptors as the
message queue, a new field has been added to the epoll event struct.
This field is checked instead of the ID value and the message queue
handler function is never called for file descriptors.

PR-URL: https://github.com/libuv/libuv/pull/2013
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Richard Lau <riclau@uk.ibm.com>

show more ...

src: move uv_free_cpu_info to uv-common.c

PR-URL: https://github.com/libuv/libuv/pull/2433
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Colin Ihrig <cjihrig@gmail.co

src: move uv_free_cpu_info to uv-common.c

PR-URL: https://github.com/libuv/libuv/pull/2433
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>

show more ...