I was looking at these 4 lines:
https://github.com/troglobit/libuev/blob/a334d23/src/uev.c#L381

if (!w->u.t.period)
	w->u.t.timeout = 0;
if (!w->u.t.timeout)
	uev_timer_stop(w);

To me this looks like when there's no initial timeout, and only a periodic timer, the timer just gets stopped after the first expiration.
Is that a bug or intended behavior?

It's not quite clear after reading docs to me: Is it possible to register new EV-handlers inside other handlers of a running loop?

Suppose I have a running net socket which handles a message like "This is the address of an endpoint, go connect to it, send there a product of this DATA, report back the result". Of course EV-style (i.e. we don't wait for the endpoint to give a result to report it back to originator, instead we register a handler on that endpoint for messages coming from it in which we find out what's the originator's connection and send there a message with a product of that endpoint's response).

For example, libuv renders network handles stalled just after initialization if init inside a handler of an event of a running loop (libuv/libuv#1505)

You know, I'm not a developer.
Trying to compile libuev on Fedora 35 I get

make  all-recursive
make[1]: Entering directory '/builddir/build/BUILD/libuev-2.3.2'
Making all in src
make[2]: Entering directory '/builddir/build/BUILD/libuev-2.3.2/src'
  CC       libuev_la-uev.lo
In file included from /usr/include/features.h:392,
                 from /usr/include/errno.h:25,
                 from uev.c:25:
/usr/include/features-time64.h:26:5: error: #error "_TIME_BITS=64 is allowed only with _FILE_OFFSET_BITS=64"
   26 | #   error "_TIME_BITS=64 is allowed only with _FILE_OFFSET_BITS=64"
      |     ^~~~~
make[2]: *** [Makefile:483: libuev_la-uev.lo] Error 1

Probably due to some changes in glibc?
In order to successfully compile libuev, it is sufficient to add -D_FILE_OFFSET_BITS=64 as a CPPFLAG in src/Makefile.am.
Is it correct?

Hi! First off I'm new to C/C++ so I want to apologize if this is a really obvious question. But after compiling/installing the library, I tried to compile the joystick example to test it out and got this:

gavin@mynamejeff:~/Projects/gamepad$ gcc `pkg-config --libs --static --cflags libuev` -o main main.c
/usr/bin/ld: /tmp/ccFVV5hW.o: in function `joystick_cb':
main.c:(.text+0x32): undefined reference to `uev_io_start'
/usr/bin/ld: /tmp/ccFVV5hW.o: in function `main':
main.c:(.text+0x15d): undefined reference to `uev_init'
/usr/bin/ld: main.c:(.text+0x185): undefined reference to `uev_io_init'
/usr/bin/ld: main.c:(.text+0x1a2): undefined reference to `uev_run'
collect2: error: ld returned 1 exit status
gavin@mynamejeff:~/Projects/gamepad$

It's worth noting, first off, that the joystick example in the docs was using the wrong include, and I happened to find the correct one linked somewhere in the README. But even when I corrected the include in the old example I got this same error. Even stranger, I removed the include from the example to verify it was being used, and indeed I get different errors upon removing it. Is it something I'm doing wrong, or does the example need to be changed?

I configured, compiled, and installed libuev on Ubuntu 18.04 and 20.04. I did sudo ldconfig. ldconfig -p shows the library:

$ ldconfig -p |grep uev
        libuev.so.3 (libc6,x86-64) => /usr/local/lib/libuev.so.3
        libuev.so (libc6,x86-64) => /usr/local/lib/libuev.so

The library is there in /usr/local/include and /usr/local/lib and pkg-config gives me:

-D_TIME_BITS=64 -D_FILE_OFFSET_BITS=64 -I/usr/local/include -L/usr/local/lib -luev

But it still won't compile the example, which I've saved as myTimer.c.

$ gcc `pkg-config --libs --static --cflags libuev` -o myTimer myTimer.c
/usr/bin/ld: /tmp/ccceRUm9.o: in function `cb':
myTimer.c:(.text+0x31): undefined reference to `uev_timer_start'
/usr/bin/ld: /tmp/ccceRUm9.o: in function `main':
myTimer.c:(.text+0x6e): undefined reference to `uev_init'
/usr/bin/ld: myTimer.c:(.text+0x9c): undefined reference to `uev_timer_init'
/usr/bin/ld: myTimer.c:(.text+0xb0): undefined reference to `uev_run'
collect2: error: ld returned 1 exit status

Any ideas?

In functions uev_run, the variable ee is declared to be an array of struct epoll_event with size UEV_MAX_EVENTS. This buffer is used in a call to epoll_wait with its maxevent parameter set to ctx->maxevents.

It may be that the intent is that ctx->maxevents can not be bigger than UEV_MAX_EVENTS, but this is not enforced in uev_init1. Therefore, with the default UEV_MAX_EVENTS set to 10, I could use uev_init1 to set the ctx->maxevents to 20, and then the ee buffer be overrun in the call to epoll_wait.

Of course, it is unlikely that so many events will occur simultaneously, so in real-life this vulnerability is very unlikely to occur. Nevertheless, I thought you might want to be aware.

libuEv uses Linux epoll which atm. does not allow monitoring of regular files. An example of this problem is the following:

echo foo | bar

works, but a text file containing foo will not work:

bar < `foo.txt`

The former is a pipe, which can be polled, the latter is a regular file, for which there currently does not exist a means of checking if a read() or write() operation would block.

This problem is quit annoying since users of libuEv usually want to provide their users with a neat symmetry at least for when reading input from stdin. Reported by @mwik

Including uev.h causes conflict in programs that carry their own modern version of the BSD queue.h file. This because libuEv uses the GNU LibC (older) version in sys/queue.h.

The following sequence makes my program segfault:

uev_timer_stop(&w);
uev_exit(&ctx);

Seems to be an ordering bug. No more segfaults
If I move the line:

uev_timer_set(w, 0, 0);

to before this section:

if (uev_watcher_stop(w))
    return -1;

Hi!
After using libuev, I encountered some questions. After setting IO non-blocking to receive data, how do different events deal with shared resources?
For example, IO events, received data is dropped to databuf, data parsing event, read data from databuf for parsing, how to solve their synchronization

The autogen.sh script fails on a Linux VM with autoconf 2.68 and automake 1.11.1 because of a missing AM_PROG_AR macro.

autoreconf: Entering directory `.'
autoreconf: configure.ac: not using Gettext
autoreconf: running: aclocal --force --warnings=portability -I m4
configure.ac:11: warning: macro `AM_PROG_AR' not found in library
autoreconf: configure.ac: tracing
autoreconf: running: libtoolize --install --force
libtoolize: putting auxiliary files in `.'.
libtoolize: linking file `./config.guess'
libtoolize: linking file `./config.sub'
libtoolize: linking file `./install-sh'
libtoolize: linking file `./ltmain.sh'
libtoolize: putting macros in AC_CONFIG_MACRO_DIR, `m4'.
libtoolize: linking file `m4/libtool.m4'
libtoolize: linking file `m4/ltoptions.m4'
libtoolize: linking file `m4/ltsugar.m4'
libtoolize: linking file `m4/ltversion.m4'
libtoolize: linking file `m4/lt~obsolete.m4'
configure.ac:12: warning: macro `AM_PROG_AR' not found in library
autoreconf: running: /usr/bin/autoconf --force --warnings=portability
configure.ac:12: error: possibly undefined macro: AM_PROG_AR
      If this token and others are legitimate, please use m4_pattern_allow.
      See the Autoconf documentation.
autoreconf: /usr/bin/autoconf failed with exit status: 1

With the following change in configure.ac the script completed successfully, and I was able to build & install libuev:

diff --git a/configure.ac b/configure.ac
index 609bb81..bba8f06 100644
--- a/configure.ac
+++ b/configure.ac
@@ -8,7 +8,7 @@ AC_CONFIG_FILES([Makefile src/libuev.pc src/Makefile examples/Makefile tests/Mak
 AC_CONFIG_MACRO_DIR([m4])

 AC_PROG_CC
-AM_PROG_AR
+m4_ifdef([AM_PROG_AR], [AM_PROG_AR])
 LT_INIT

 # Optional features

I didn't yet manage to test this with a newer autoconf version.

Supporting older autoconf versions will be useful for those of us maintaining older code. :)

Thanks very much!

Just to know. Why "forcing" that instead of using flags used in the other Makefile?

Would you like to replace any defines for constant values by enumerations to stress their relationships?

AM_CONFIG_HEADER
Automake will generate rules to automatically regenerate the config header. This obsolete macro is a synonym of AC_CONFIG_HEADERS today (see section 5.2 Other things Automake recognizes).

https://ftp.gnu.org/old-gnu/Manuals/automake-1.7.2/html_chapter/automake_5.html#SEC23

I successfuly built libuev on a musl based system after applying the folloving patch:
in essence removing test.c which was moved to examples dir.

--- ./Makefile.orig     2015-02-15 18:30:30.000000000 +0100
+++ ./Makefile  2015-02-15 21:12:03.081389097 +0100
@@ -46,7 +46,7 @@
 libdir     ?= $(prefix)/lib
 datadir    ?= $(prefix)/share/doc/$(LIBNAME)
 incdir     ?= $(prefix)/include
-DISTFILES   = README CHANGELOG TODO LICENSE test.c
+DISTFILES   = README CHANGELOG TODO LICENSE
 HEADER      = uev.h

 OBJS       := uev.o io.o timer.o signal.o

Possibly it could support 64 bit time_t with glibc with the help of __USE_TIME_BITS64?
Other libc's may follow.
(__USE_TIME_BITS64 is Glibc's time_t fix for 32 bit CPUs.)

Just thinking...

Using the following: (1) it runs perfectly on BSD's and BSD-like such as macos and ios; plus, recent Android sub-systems also seem to handle it properly (wasn't always the case as Android is maybe based on a linux kern, however, it departed from the original design to put it politely).

For windows, there is an existing epoll port; (2) but I did not try it yet; don't know if it fairly runs. (These days windows support AF_UNIX or AF_LOCAL, see limitation about file-descriptor, so it would require some minor abstraction work, which is still better than libev plastering i.e only relaying on third party implementations of epoll; descriptor could be a struct holding the specific handle with the minimal set of i/o operations associated with mainly close and read... uev_epool_descriptor_t uev_epool_{}()).

edit info: possible cross-platform standalone unified-epool layer:
posix read/write syscalls Win32:
-- socket recv/send
-- I/O ReadFile/WriteFile support win-socket handles.

/* unified epoll front-end */

typedef struct
{
	SOCKET u_client;
	SOCKET u_listen;
} uepoll_socket_fd_t;

typedef union
{
	int    u_fd;
	HANDLE u_hnd;
} uepoll_file_fd_t;

typedef union
{
	uepoll_file_fd_t   u_file;
	uepoll_socket_fd_t u_sock;
} uepoll_fd_t;

typedef struct epoll_event uepoll_event_t;

/* unified I/O front-end */

uepoll_fd_t uepoll_open(const char * path, uepoll_fd_flag_t flag, ...)
{
// Case windows socket open rw;
	uepoll_fd_t fd;
	SOCKADDR_UN sock_un = { 0 };
	 
	if (INVALID_SOCKET != fd.u_sock.u_listen = socket(AF_UNIX, SOCK_STREAM, 0)) {
		sock_un.sun_family = AF_UNIX;
		strncpy_s(sock_un.sun_path, sizeof sock_un.sun_path, SERVER_SOCKET, (sizeof path) - 1);
		if (SOCKET_ERROR != bind(fd.u_sock.u_listen, (struct sockaddr *)&sock_un, sizeof(sock_un))) {
			if (SOCKET_ERROR != listen(fd.u_sock.u_listen, SOMAXCONN)) {
				if (INVALID_SOCKET != (fd.u_sock.u_client = accept(fd.u_sock.u_listen, NULL, NULL))) {
					...
				}
				...
			}
			...
		}
		...
	}
	...
}

uepoll_ssize_t uepoll_read(
	  uepoll_fd_t fildes
	, void *      buf
	, size_t      nbyte
);

uepoll_ssize_t uepoll_write(
	  uepoll_fd_t  fildes
	, const void * buf
	, size_t       nbyte
);

uepoll_fd_t uepoll_create(int size);
uepoll_fd_t uepoll_create1(int flags);

int uepoll_ctl(
	  uepoll_fd_t      epfd
	, int              op
	, uepoll_fd_t      fd
	, uepoll_event_t * event
);

int uepoll_wait(
	  uepoll_fd_t      epfd
	, uepoll_event_t * events
	, int              maxevents
	, int              timeout
);

1- https://github.com/jiixyj/epoll-shim
2- https://github.com/piscisaureus/wepoll

I think, I am going to write a standalone draft document about making an unified header-only frontend where the heavy lift is handled by third-party implementations or native; if people want to join on puzzling what would be the best/fair approach you are welcome.

I would like to point out that an identifier like “_SYS_QUEUE_H_” does eventually not fit to the expected naming convention of the C language standard.
Would you like to adjust the selection for unique names?

Hi,
I have submitted an ebuild to gentoo with libuev. On my machines with gcc 5.4 everything works fine.

 $ gcc-config -l
 [1] x86_64-pc-linux-gnu-5.4.0 *

However, I have received a bug which reports breakage with x86_64-pc-linux-gnu-7.2.0.
https://bugs.gentoo.org/640202