From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22287 invoked by alias); 9 Feb 2002 07:53:21 -0000 Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Received: (qmail 22230 invoked from network); 9 Feb 2002 07:53:21 -0000 Received: from unknown (HELO itdomain003.itdomain.net.au) (203.63.157.208) by sources.redhat.com with SMTP; 9 Feb 2002 07:53:21 -0000 Received: from lifelesswks ([144.137.122.216]) by itdomain003.itdomain.net.au with Microsoft SMTPSVC(5.0.2195.3779); Sat, 9 Feb 2002 18:53:19 +1100 Message-ID: <00f001c1b13e$e90bfc10$0200a8c0@lifelesswks> From: "Robert Collins" To: "Ralf Habacker" , "cygwin" References: <000e01c1af19$013888d0$01000001@BRAMSCHE> Subject: Re: unix domain socket with shared memory ? Date: Fri, 08 Feb 2002 23:53:00 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-OriginalArrivalTime: 09 Feb 2002 07:53:19.0829 (UTC) FILETIME=[D71EC050:01C1B13E] X-SW-Source: 2002-02/txt/msg00466.txt.bz2 === ----- Original Message ----- From: "Ralf Habacker" To: "cygwin" Sent: Thursday, February 07, 2002 1:17 AM Subject: unix domain socket with shared memory ? > Hi all, > > cfg has told me about the current process of cygwin daemon implementation with ipc support. > > I initial have heard last year, that this work would be started, but because of so much other work I have lost the > contact to the ongoing process. It's currently paused, waiting for the development team to persuade Chris that the _core_ (not the IPC part) is ready for (finaly filenaming and then) inclusion. > Now I was looking into the ongoing work and it seems to me in a mostly read state, isn't it. I like to say: Great > work to all who have worked on it. :-) Thank you. The main folk are Egor Duda who created an inital proof-of-concept for solving a security issue, most of the developers list bouncing round ideas, and then I (*bow*) took Egors proof of concept and created the generic daemon, and the win9x support that it now has. Gary R. Van Sickle has also spent some time recently being a guinea pig, which I appreciate :]. > The reason why I'm writing this is that I have recognized some performance issues with unix domain sockets, which ... > Because the cygwin-daemon branch provides the long missed ipc support, the way for for speeding up unix domain > sockets with a shared memory implementation may be free. (I not be not first one, who tells about this, because I > have seen some guys before talking about this possibility) Hmm, the cygwin-daemon IPC implementation may allow this, but so does the existing mmap implementation. So I think a better approach may be via mmap (more mature code) with the daemon providing cross-process-persistence (if needed). > One open topic for me is how to handle forking. I imagine, that because the file handles are duplicated, the shared > memory has to be duplicatd too, but because the socket file name is the same, does it use the same shared memory > area as the parent or not ??? Forking is easy to implement (see the fixup_after_fork functions) but shouldn't be needed if implemented on top of mmap or IPC memory regions. What maybe an issue is the logic for how it should behave. If you write, who reads? The parent or the child? The first reader? Once this question is answered, you will find making fork() work straight forward. Advice can be offered at that point if needed. > My intention whis this thread is to make sure, that this strategy is a possible way and I'm willing to spent some t > ime to get this running, although I think I'm not be able to handle this whole task alone. Yes, it's possible. Is the daemon needed? Maybe not, maybe. You will get assistance in doing this. Rob -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/