Re: kcomd and others/race condition

On Fri, Jun 09, 2006 at 09:49:57PM +0200, Stephan Schmid wrote:
> I just thought of the case in which there is a problem between data
> and command transfers.  It might prevent the race condition if the
> deputy stub does not send any commands to the remote part directly
> over the connection between them. If there is a request for migrating
> home deputy just sets itself into an queue of an migrate_home_kthread
> and continues with normal work (answering). The daemon connects it
> remote partner and tells him that this specific task wants to return
> home. This daemon however makes a request to the specific remote task
> to migrate back home and the remote task tells after some time the
> deputy part that it wants to go home.  I think that signals could be
> processed similarly except that the daemon on remote has to ensure
> that the process is still on remote and, if not, send the signal back
> home.  This would ensure that all operations are processed one by one,
> I think.  Please tell me if I did some misunderstandings on how OM
> works or if there is something bad with that idea.

A task goes home by itself. So the migration back can be done at the
moment it suit its need. If the task is in middle of something else,
ex. waiting a syscall reply, it will process the migrate to home after
namely in openmosix_pre_usermode (just before returning to userhome)

-- 
Vincent Hanquez