Re: race condition?

On Thu, 2006-05-25 at 13:25 +0000, Vincent Hanquez  wrote:
On Mon, May 22, 2006 at 06:34:29PM -0600, Matt Dew wrote:
> > This makes sense.
> > Plus if it were ever desired, adding things to a central place would
be
> > easier.. Things like:
> > 1)  encrypting the traffic between nodes.
> 
> yes, and authentification as well.
> 
> > 2)  d-bus messages on migration events
> 
> I'm not sure what d-bus is useful for here ? care to elaborate ?

Notification to balancer?  Heuristics analyzer/collection?  general
userspace notification?

My example:
  I'm an electrical engineer and I want to be able to have my desktop
machine on a cluster so I'd like to have KDE (or gnome or whatever) pop
up a passive notice saying "Process migration received from
EvenSlowerMachine" or "Now migrating process 8192 [synplify_pro] to
FastMachine ..."

<snip>

> 
> I'm not yet sure on the best way to interact with kcomd ..
> altough kcomd will have a queue of messages to send tagged with the
> mode of sending (do we put the process for sleeping waiting for ACK,
> ...), and the pid of the sender.
> 
> For receving, there's 2 differents things:
> 	- expected replies
> 	- unexpected replies.
> 
> In the former case, the process has been put to sleep, since it has
used
> send_with_ack()/reply(). kcomd will just put the process in the
running
> list. the process will wake up with new data or a ack/nack.
> 
> In the later case, the process poll is there's message pending for
> itself and do something with packet if there is any.
> (this is actually done in remote_pre_usermode, but currently check for
> data in socket instead of the new way).
> 


Something like this: (very high level)

For sending: [ send_with_ack()/reply()  ]

down(&addingtolist_mutex);  // preempty safety
list_add_tail(&stuff, &send_list_head);  // queue up our comm.
init_mutex_locked(&this_stuff_has_been_ackedreplied);  // kcomd up's
this mutex when it has received ack/reply, so process can sleep until
data is ready
up (&addtolist_mutex);  // we're good.

down(&this_stuff_has_been_ackedreplied); // sleep until kcomd has
(n)ack/reply

return(&stuff->reply)

---


kcomd():

for (;;) {

   if (&send_list_tail->next != NULL) {  // new comms?
      comm_send(&stuff, p->om.contact)
      list_add_tail(&stuff, &waiting for response_head);
   }

   recv=comm_recv(&stuff);
   // loop through and find corresponding process
   if (recv) 
     list_for_each(p, &waiting for response_head) {  
        my=list_entry(p, struct omstruct, id)
        if (id ==  stuff->id)
           myprocitem=get_process_pointer(stuff->pid)   
           if (expected(myprocitem, stuff) { // ??
              up(myprocitem->this_stuff_has_been_ackedreplied) //
release mutex and wake up process
              list_del(myprocitem);
           } else {
              add_to_list(myprocitem->unexpected, stuff); // handle by
om_pre_usermode?
           }
    }
}

Thoughts?
Matt




-------------------------------------------------------
All the advantages of Linux Managed Hosting--Without the Cost and Risk!
Fully trained technicians. The highest number of Red Hat certifications in
the hosting industry. Fanatical Support. Click to learn more
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=107521&bid=248729&dat=121642