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.
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...
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