Project

General

Profile

Actions

Bug #14912

open

non-blocking port_get() returns 0 when there are no events

Added by Robert Mustacchi about 2 months ago. Updated about 2 months ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
kernel
Start date:
Due date:
% Done:

0%

Estimated time:
Difficulty:
Medium
Tags:
Gerrit CR:
External Bug:

Description

This is a variant of sorts of #11910. In this case, both port_get() and port_getn() (because port_get is a wrapper around port_getn()) have the behavior where if you specify a zero timeout, that is a non-blocking event, then when there are no events available, port_get() and port_getn() return 0. In the case of port_getn() you can at least check the nget parameter to determine how many such events were retrieved, but with port_get() you have no such means available to you.

In the kernel, when we have a zero timeout, the logic in port_get_timeout determines thiat this is a non-blocking event and therefore doesn't even bother enqueuing this thread in the list of waiting ones and instead just goes through and looks at how many events there actually are available (this is the portnowait label). The fundamental problem is that when we look at our nevents == 0 logic in this part of the code after copying things out:

1543 
1544         if (nevents == 0 && error == 0 && pgt->pgt_loop == 0 && blocking != 0) {
1545                 /* no events retrieved: check loop conditions */
1546                 if (blocking == -1) {
1547                         /* no timeout checked */

We don't consider the non-blocking case and therefore as there is no error, but no events, just return zero.

Naively, I would have thought that this case would return -1 and set errno to ETIME, but it clearly doesn't. While you can almost handwave around this with port_getn(), there really is no way to know that the port was actually filled in or not which makes this rather challenging. This is related to the similar problem in #11910 where things are returning ETIME but there are valid events in there. This is likely do to similar parts of construction and how the pgt_loop suff is being tracked.


Related issues

Related to illumos gate - Bug #11910: port_getn fails with ETIME, even though events are deliveredNew

Actions
Actions #1

Updated by Robert Mustacchi about 2 months ago

  • Subject changed from port_get() returns 0 with no events with 0 timeout to non-blocking port_get() returns 0 when there are no events
Actions #2

Updated by Robert Mustacchi about 2 months ago

  • Related to Bug #11910: port_getn fails with ETIME, even though events are delivered added
Actions

Also available in: Atom PDF