[prev in list] [next in list] [prev in thread] [next in thread] 

List:       dlm-devel
Subject:    Re: [Dlm-devel] clm_master_loop()
From:       Alan Jones <alan.jones () sun ! com>
Date:       2001-04-09 19:32:04
[Download RAW message or body]

I thought of a 3rd possiblity:  merge the "scheduler" queue and the
cluster manager work queue.  You might still need a lock to sequence
the work being done in the receive thread with the master loop.

Alan


> > I think what's missing is the "kick" from cccp into dlmdk to inform it to
> > process incoming data.  This is what happens from the dlmdu side, when there
> > are incoming cluster events.  As you describe, the clm_master_poll() before
> > just had a number of file descriptors.
> 
> The original code was essentially doing a select() to multiplex two imput
> streams:  incoming network messages and cluster manager events.  The
> current code does have a "kick" for new cluster events in the semaphore
> up in dlm_workqueue_put_work().  You can't have two "kicks" within one
> loop unless you time out the sleeps which is tacky and slow.
> 
> I have two suggestions that would be consistent with the current design.
> 
> 1. merge the cluster manager and incomming message queues; i.e use
>    dlm_workqueue_put_work() to queue messages as well
> 
> 2. break out the "scheduler" loop from clm_master_loop(), put a semaphore
>    or other sleepable lock around it, and call it from both the master
>    loop and at the end of all message processing routines (e.g. clmr_cntrl())
> 
> I favor #2 because #1 introduces a another context switch in the
> incomming message processing.  There is already one context switch from the
> interrupt to queue and signal a thread waiting in recvmsg().
> 
> Alan
> 


[prev in list] [next in list] [prev in thread] [next in thread]