pcp
[Top] [All Lists]

Re: [pcp] pcp updates: PM_ERR_TIMEOUT protocol changes

To: pcp@xxxxxxxxxxx
Subject: Re: [pcp] pcp updates: PM_ERR_TIMEOUT protocol changes
From: Ken McDonell <kenj@xxxxxxxxxxxxxxxx>
Date: Wed, 3 Aug 2016 10:16:50 +1000
Delivered-to: pcp@xxxxxxxxxxx
In-reply-to: <1771069354.13011445.1470098488567.JavaMail.zimbra@xxxxxxxxxx>
References: <20160801101257.3C8855A00D5@kenj> <1771069354.13011445.1470098488567.JavaMail.zimbra@xxxxxxxxxx>
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0
On 02/08/16 10:41, Nathan Scott wrote:
Hi Ken,

----- Original Message -----
...
I guess the other place to still consider is the pmlc PDUs, but they
are never multiplexed so probably not an area to really worry about.

These were already accounted for, but I've done a better job of this and the other outlier __pmGetPDU() uses in the Mk II commit ... I think this is done now in terms of appropriate checks and actions after all the __pmGetPDU() uses.

I can't see any issues here.  One slight tweak that might be worth
doing (maybe later - its an internal routine only) would be to have
the new __pmCloseChannel routine pull in the two lines that always
follow it, i.e. fixing up the error code to be one of TIMEOUT/IPC,
and returning that, instead of open-coding that logic for each PDU.

I considered this when I refactored __pmCloseChannel -> {__pmCloseChannelbyContext and __pmCloseChannelbyFd} but decided not to.

I did not want to pass a int * status into the reporting routine and then have the caller logic obfuscated by some hidden change to the value of a (usually) local variable.

<Prev in Thread] Current Thread [Next in Thread>