PackedWaker / PackedList in waker.zig was quickly written and could possibly be improved. It takes a Set which is a packed struct of booleans representative of a bitset.

The PackedWaker is used for signal handling, where Set is the set of possible signals that a caller may suspend themselves on.

Upon the notification of a signal being received by a process, should any of the received signals match any callers waited-upon signals, the suspended caller would be resumed.

Once this feature is done, I will move signal handling on linux/darwin to utilize sigaction to be able to catch all signals directed towards a process unlike signalfd or kqueue EVFILT_SIGNAL to keep signal handling behavior consistent across platforms.

I'm getting the following errors when compiling a project that uses pike:

/home/duane/Projects/cleartouch/lib/pike/os/windows.zig:35:25: error: use of undeclared identifier 'c_void'
        @ptrCast(*const c_void, &guid),
                        ^
/home/duane/Projects/cleartouch/lib/pike/os/windows/ws2_32.zig:82:21: error: use of undeclared identifier 'c_void'
    lpSendBuffer: ?*c_void,
                    ^

I believe c_void is now anyopaque. I think it may have been backported to zig 0.9.0? Not sure though.

pike.init() / pike.deinit() are only used to initialize winsock2 on Windows. A global atomic counter may be used to silently initialize winsock2 upon the very first Socket.init() call, and silently de-initialize winsock2 on the very last Socket.deinit() call.

On Windows, Socket.call() is responsible for driving the asynchronous execution of a socket I/O syscall.

What needs to be done is that prior to the execution of a syscall, an async frame should be queued to an atomic queue of frames stored in a Socket. Upon executing Socket.deinit(), all frames should be forcibly resumed with a flag that would cause error.OperationCancelled to be returned by Socket.call().

This is just an idea so far, though the idea is that for each exposed syscall (e.g. read()), there would be two variants: Socket.read(buf: []u8) !usize, and Socket.readAsync(buf: []u8) callconv(.Async) !usize.

Another method would be exposed, which is Socket.wait(.{ .read = ?, .write = ? }) callconv(.Async) void which allows users to manually await until a read/write-readiness notification is provided by an I/O notifier for a given file handle.

Calling Socket.read(...) will return immediately if the syscall cannot immediately be completed, and thus may be driven by Socket.wait(.{ .read = true }). Calling Socket.readAsync(...) will automatically retry the syscall, which is done by awaiting for readiness notifications from an I/O notifier via Socket.wait(.{ .read = true }).

Exposing these two variants also allows for Socket's in pike to be used in blocking mode (e.g. read() / write() may be called directly, blocking the current thread until said read() / write() is completed).

As of right now, Socket.get() and Socket.set() assume that the level parameter which is passed to getsockopt() / setsockopt() os SOL_SOCKET.

However, there exist other options that don't necessarily assume the level parameter is SOL_SOCKET, such as TCP_NODELAY.

To expose these other options, the idea is to replace the tag payload types of the union SocketOption with a tuple of length two comprised of the level and option parameter.

Pike right now has three configurable build flags:

• pike_task: struct type representing an asynchronous task.
• pike_batch struct type representing a batch of asynchronous tasks.
• pike_notifier struct type representing an I/O notifier implementation.

They are overridable via @import("root") at the moment, which is not the best option. Ideally, these flags should be configurable in build.zig for example. Rust exposes configurable build flags via Cargo.toml, in which libraries can configure flags for library dependencies they themselves depend on. Still need to figure out the best option in Zig.

I'm struggling to create what seems like should be a very basic use of pike: listen to two file descriptors, and if anything is read, print it out (without blocking).

My use case is I'd like to listen to several linux evdev devices (mouse, touchpad, keyboard for example).

I tried using example_event.zig as a starting off point, but I'm failing to understand how to connect file descriptors to a Notifier (I think?)

I'm also unsure why, when notifier.poll(10_000) is called in the example, it doesn't wait 10 seconds like I expect it should... unless it's actually receiving events, but then, what events is the example receiving?

Anyway, I'm new to Zig but like what I see here and just thought I'd write here in case this use case might help make Pike easier to pick up for others.

Thanks.

Error sets should be well-defined with the documentation for methods of Socket across platforms. Unit tests should be written to also demonstrate that behavior across platforms for the intersection set of methods shared across platforms is consistent.

Sockets on Windows are represented by a ws2_32.SOCKET, unlike generic file handles which are represented by windows.HANDLE.

To cleanup all the verbose @ptrCast(ws2_32.SOCKET, self.handle.inner) casts in socket_windows.zig, it would be ideal to separate the file handle from pike.Handle.

Doing so would also allow removing unnecessary fields, such as async types that do not require a file handle (e.g. signal_posix.zig).