kqueue modify handling of events looks weird

[fogti]

This code segment

polling/src/kqueue.rs

Lines 101 to 124 in bc56d1f

	// Apply changes.
	let mut eventlist = changelist;
	syscall!(kevent(
	self.kqueue_fd,
	changelist.as_ptr() as *const libc::kevent,
	changelist.len() as _,
	eventlist.as_mut_ptr() as *mut libc::kevent,
	eventlist.len() as _,
	ptr::null(),
	))?;
	// Check for errors.
	for ev in &eventlist {
	// Explanation for ignoring EPIPE: https://github.com/tokio-rs/mio/issues/582
	if (ev.flags & libc::EV_ERROR) != 0
	&& ev.data != 0
	&& ev.data != libc::ENOENT as _
	&& ev.data != libc::EPIPE as _
	{
	return Err(io::Error::from_raw_os_error(ev.data as _));
	}
	}
	Ok(())

looks incredibly weird, because it seems that it should be able to basically drop arbitrary oneshot events which occured, as any "non-error" events don't get handled there at all. I would be in favor of not doing any event handling there and just pass an empty eventlist instead to prevent that, handling errors at the next wait instead, which imo would be much cleaner (and won't exhibit such race conditions).

[notgull]

This might be the bug I'm running headlong into in #59.

[fogti]

@notgull I don't think it's the bug you're running into, because I think this should only affect multi-threaded stuff, and the ordering in the test you used didn't use any interleaving or such that could explain that.

[notgull]

Looking at mio, it looks like it uses EV_RECEIPT to ensure that the internal buffer is always filled up with receipt events. Using that might fix this issue. Wait, sorry, we already use that, I missed that. In that case, I don't think there should be any real issues.