From owner-p4-projects@FreeBSD.ORG Tue Oct 23 21:40:48 2007 Return-Path: Delivered-To: p4-projects@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 32767) id 84C8716A41B; Tue, 23 Oct 2007 21:40:48 +0000 (UTC) Delivered-To: perforce@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A10BF16A419 for ; Tue, 23 Oct 2007 21:40:47 +0000 (UTC) (envelope-from zec@icir.org) Received: from xaqua.tel.fer.hr (xaqua.tel.fer.hr [161.53.19.25]) by mx1.freebsd.org (Postfix) with ESMTP id 3701E13C4A5 for ; Tue, 23 Oct 2007 21:40:47 +0000 (UTC) (envelope-from zec@icir.org) Received: by xaqua.tel.fer.hr (Postfix, from userid 20006) id 91A829B653; Tue, 23 Oct 2007 23:14:43 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on xaqua.tel.fer.hr X-Spam-Level: X-Spam-Status: No, score=-4.3 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.7 Received: from [192.168.200.100] (zec2.tel.fer.hr [161.53.19.79]) by xaqua.tel.fer.hr (Postfix) with ESMTP id CAD9C9B648; Tue, 23 Oct 2007 23:14:42 +0200 (CEST) From: Marko Zec To: Julian Elischer Date: Tue, 23 Oct 2007 23:14:37 +0200 User-Agent: KMail/1.9.7 References: <200710230018.l9N0IO8l020652@repoman.freebsd.org> <471D4514.5050109@elischer.org> In-Reply-To: <471D4514.5050109@elischer.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200710232314.38149.zec@icir.org> Cc: Perforce Change Reviews , Marko Zec Subject: Re: PERFORCE change 127942 for review X-BeenThere: p4-projects@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: p4 projects tree changes List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2007 21:40:49 -0000 On Tuesday 23 October 2007 02:49:24 Julian Elischer wrote: > question: > > can processes in two vimages communicate if they both have access > to the same named pipe/fifo in the filesystem? Yes, provided that they open the fifo while they would be both attached to the same vnet. Once the sockets would become open the processes could reassociate to arbitrary vimages, while the sockets would remain bound to their original vnets for their entire lifetime duration. As an alternative, we could / should introduce an extended socket() syscall where an additional argument would explicitly specify to which vimage/vnet the new socket should belong. Marko