From mboxrd@z Thu Jan 1 00:00:00 1970 Message-Id: From: Nemo To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (iPad Mail 7B500) Date: Fri, 15 Oct 2010 19:54:09 +0200 References: <10af1064d3ac35a8d2f62214d5eec485@gmx.de> Subject: Re: [9fans] =?utf-8?b?z4Bw?= Topicbox-Message-UUID: 66c07b06-ead6-11e9-9d60-3106f5b1d025 back to the 80s, or was it 70s? many people have implemented migration. the first i remember is swaping (yes, not paging) out a process, then = swapping it back into a different machine. iirc, it might be the sprite unix, not = quite sure. the point is, the migrated process still needs all the connections it = had with the outer world in the old location. perhaps, some of them to other = processes still at the old location. they got it working, but they were caught in the = resulting spaghetty.=20 So, when I hear migration, I just tend to see what happens after it has been implemented and faces the spaghethy phase. Of course it might be just that this word scares the hell out of me. On Oct 15, 2010, at 6:28 PM, Lyndon Nerenberg wrote: >> i wonder if making 9p work better over high latency connections is >> even the right answer to the problem. the real problem is that the >> data your program wants to work on in miles away from you and >> transfering it all will suck. would it not be cool to have a way to >> teleport/migrate your process to a cpu server close to the data? >=20 > This works when you can colocate CPU with the data. But think of = sensor networks where the data lives on very cpu- and power-challenged = SOCs behind, e.g., high-latency radio links. >=20 > --lyndon >=20