Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1409767

Summary: The API glfs_h_poll_upcall cannot return 0 and set an errno to denote no entries
Product: [Community] GlusterFS Reporter: Shyamsundar <srangana>
Component: libgfapiAssignee: Arjun <arjsharm>
Status: CLOSED UPSTREAM QA Contact:
Severity: low Docs Contact:
Priority: low    
Version: mainlineCC: bugs, jthottan, ndevos, skoduri
Target Milestone: ---Keywords: EasyFix, Triaged
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2020-03-17 03:37:29 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Shyamsundar 2017-01-03 09:58:43 UTC
As per the errno man page,
"The  <errno.h> header file defines the integer variable errno, which is set by system calls and some library functions in the event of an error to indicate what went wrong.  Its value is significant
       only when the return value of the call indicated an error (i.e., -1 from most system calls; -1 or NULL from most library functions); a function that succeeds is allowed to change errno."

The interface for this function expects the consumer to check either the cbk or the errno on success, the latter is either incorrect, or the code in gfapi needs to reset errno to 0 on success to ensure that the errno returned when the call succeeds is zero.

This bug is to track and change this behavior or provide rationale for the current state of the API.

Comment 1 Niels de Vos 2017-01-09 13:31:20 UTC
My preference goes to setting errno to 0 in case the of success. But according to the man-page, this needs to be done by the application before calling the function (glfs_h_pull_upcall() in this case).

Applications checking for the returned cbk object are taking a pretty safe route :)

I am not sure what the implications would be to return -1 when there are no upcalls pending. This needs to be investigated among the users of the API. If this breaks applications, we can add a versioned symbol, but that adds some maintenance overhead as well...

Comment 2 Worker Ant 2020-03-17 03:37:29 UTC
This bug is moved to https://github.com/gluster/glusterfs/issues/1119, and will be tracked there from now on. Visit GitHub issues URL for further details