[Sheepdog] [PATCH 1/2] sheep: sheep: handle node change event first

[Liu Yuan]

On 04/01/2012 07:12 PM, MORITA Kazutaka wrote:

> At Sun, 01 Apr 2012 18:31:24 +0800,
> Liu Yuan wrote:
>>
>> On 04/01/2012 04:47 PM, MORITA Kazutaka wrote:
>>
>>>>> Let's leave aside IO req that are just queued, not issued.
>>>>>
>>>>> Even with separate queues, seems that we need to wait for completion of
>>>>> infly IOs. No?
>>> Yes.
>>>
>>
>>
>> So either way, we need to wait for infly io. This brings problem, since
>> queuing is processed in main thread.
> 
> Yes, but succeeding membership messages can be processed immediately
> because we can skip I/O requests in cpg_event_siblings, no?
> 
>>
>>>>>
>>>>> So one queue with higher priority placement of notify & confchg event,
>>>>> we could have a working solution.
>>> Yes, I guess it will work.  I thought it is simpler to use two queues
>>> than traversing one queue to find the proper placement, though.
>>
>>
>> Placement is very simple, that is why I used a single queue, just
>> inserting it at head, since if there is no infly IO hanging around, we
>> are guaranteed that the event in the head of the queue will be processed
>> immediately.
> 
> But some nodes may have outstanding I/Os but the others may not...
> 
> I really don't understand how all nodes process events in the same
> order if we add them to the head of the FIFO queue.  Some nodes can
> process messages in the delivered order, but the other ones can do
> them in the reverse order if there are pending messages.  I think it
> is not good at all to process messages in the different order from the
> multicasted order.
> 
> Maybe, I'm missing some points.  If it is not difficult to implement
> those, I'd like to see the code.
> 


Hmm, maybe we are talking the same thing with different focus. I give it
a second thought, I'll try two queue, since it might need smallest changes.

Thanks,
Yua