Mailing-List: contact cygwin-developers-help AT sourceware DOT cygnus DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-developers-owner AT sources DOT redhat DOT com Delivered-To: mailing list cygwin-developers AT sources DOT redhat DOT com Date: Thu, 31 May 2001 14:06:36 -0400 From: Christopher Faylor To: cygwin-developers AT cygwin DOT com Subject: Re: [RFD]: Egor's proposal for a Cygwin server process Message-ID: <20010531140636.E23914@redhat.com> Reply-To: cygwin-developers AT cygwin DOT com Mail-Followup-To: cygwin-developers AT cygwin DOT com References: <20010531124452 DOT G1870 AT cygbert DOT vinschen DOT de> <48146951254 DOT 20010531164356 AT logos-m DOT ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.11i In-Reply-To: <48146951254.20010531164356@logos-m.ru>; from deo@logos-m.ru on Thu, May 31, 2001 at 04:43:56PM +0400 On Thu, May 31, 2001 at 04:43:56PM +0400, egor duda wrote: >Hi! > >Thursday, 31 May, 2001 Corinna Vinschen vinschen AT redhat DOT com wrote: > >CV> I would like to revive the discussion about a sort of server process >CV> providing critical services to Cygwin processes. > >CV> The reason is that I found another good example how such a server >CV> could be used: s-uid and s-gid applications and files. > >looks reasonable. not that i particularly miss suid bits, but i'd >probably use it extensively if/when it'll be implemented. > >CV> So, as far as I can see, we have already three reasons to >CV> invent that server process: > >CV> - Secure handles >CV> - IPC >CV> - s-uid, s-gid facility > >CV> I think we will find more later on. > >CV> So, how is the current "mood" related to such a server process >CV> and how keen are people to work on that? > >CV> Has somebody a suggestion how to interact with that server process? >CV> Sockets? Named pipes? Smoke signals? > >I'd try to range them from the different points of view: >(first is better, last is worse) > >Security: >1. Named pipes. >2. Shared memory (?). >3. Sockets. >4. Smoke signals. > >Performance (including both latency and throughput): >(*** this is pure speculation, some testing required ***) >1. Named pipes. Shared memory. (not sure which is better) >2. Sockets. >3. Smoke signals. > >Cross-platform support: >1. Smoke signals. :) >2. Shared memory. >3. Sockets. (don't forget, user may want to use cygwin on machine with >no networking installed) >4. Named pipes (nt/2000 only) > >a communication between client and server is restricted to local host >only, so, i suppose, we can take "mixed" approach -- use named pipes >on nt/2000 and shared memory on w9x. > >but first, i'd try to do some performance testing. I wouldn't expect a high amount of throughput from the smoke signals but they do fall right in line with the cygwin computer heating features. cgf