> > Where/how is callcnt set, and decremented?
> The following are the two structures which hold 'state' information
> of
> mgmt ops in progress on a synctask,
> struct gd_aggr_ {
> int call_cnt;
> int npeers;
> gf_lock_t lock;
> int op_ret;
> int op_errno;
- Original Message -
>
>
>
> On Wed, Feb 13, 2013 at 8:37 PM, krish < kpart...@redhat.com > wrote:
>
>
>
>
> The strategy is to defer yield'ing of the task till a mgmt operation
> is sent to all the peers.
>
> If I understand it right, the following theorem is true,
> - A function
On Wed, Feb 13, 2013 at 8:37 PM, krish wrote:
> The strategy is to defer yield'ing of the task till a mgmt operation is
> sent to all the peers.
>
> If I understand it right, the following theorem is true,
> - A function which begins execution in a synctask (ie. thread from
> syncenv's thread po
The strategy is to defer yield'ing of the task till a mgmt operation is
sent to all the peers.
If I understand it right, the following theorem is true,
- A function which begins execution in a synctask (ie. thread from
syncenv's thread pool), would always
resume execution (ie, wake) in the sa
So you are not using the SYNCOP() macro, right? Can you show a code snippet
of how you are trying to fan-out and yield? We could probably come up with
a generic framework for such fan-out->yield->wake pattern.
You should be able to call syncop_yield() instead of __yield() if you are
_sure_ that th
In glusterd, I am trying to perform a series of syncops in a batch. ie, yield
the thread
once all the non-blocking operations are queued. The wakeup back to the yielded
thread
happens as part of the call_cnt mechanism in the callback(s).
Given this, I wanted to know if I would be flouting any of
