[sheepdog] [PATCH v2 3/4] sheep: handle block/unblock/notify error
Kai Zhang
kyle at zelin.io
Tue Jul 9 04:33:12 CEST 2013
On Jul 9, 2013, at 10:26 AM, Liu Yuan <namei.unix at gmail.com> wrote:
> On Tue, Jul 09, 2013 at 10:15:50AM +0800, Kai Zhang wrote:
>>
>> On Jul 9, 2013, at 8:43 AM, MORITA Kazutaka <morita.kazutaka at gmail.com> wrote:
>>
>>> I think block/unblock/notify should return SD_RES_xxx since they know
>>> the error reason rather than the callers. Currently, all the
>>> callbacks only can return SD_RES_CLUSTER_ERROR or SD_RES_SUCCESS,
>>> though.
>>
>>
>> Here is my personal opinion.
>>
>> I think SD_RES_xxx is used as return code to external module (other sheep and client)
>> to indicate the error of a request.
>
> No, we don't have this assumption. Mostly we recommend return SD_RES_XXX between
> functions and modules, return -1, 0 only if it is hard to do so.
>
>> However, block/unblock/notify are internal functions who don't know they are serving for
>> external requests.
>> I think, we can indicate internal error by logging and only use return code '-1' when fail.
>> It is the caller's responsible (here the caller is queue_cluster_request) to mark the result
>> as SD_RES_xxx.
>>
>> The drawback is that we cannot know the specific error from return code.
>> However, as an internal function, I think only use 0 and -1 as return code is enough.
>
> You already said the benefit, even though currently return 0 and -1 equal SD_RES_XXX
> because we only have binary ret state, but in the long run, we might add more
> ret state in the future.
>
I see.
So I think we should also return SD_RES_xxx for init/join/leave/update_node.
I would like to update them in a separate patch later.
Thanks,
Kyle
More information about the sheepdog
mailing list