Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com Date: Sun, 27 Jun 2004 15:42:05 -0400 From: Christopher Faylor To: cygwin AT cygwin DOT com Cc: "Pierre A. Humblet" Subject: Re: higher-level IO very slow with cygwin1.dll 5.10 (due to set_flags?) Message-ID: <20040627194205.GA10371@trixie.casa.cgf.cx> Reply-To: cygwin AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com, "Pierre A. Humblet" References: <20040626154504 DOT GA961349 AT hpn5170x> <20040626160554 DOT GA980221 AT hpn5170x> <20040626170940 DOT GD20063 AT trixie DOT casa DOT cgf DOT cx> <20040626174145 DOT GA1032441 AT hpn5170x> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040626174145.GA1032441@hpn5170x> User-Agent: Mutt/1.4.1i On Sat, Jun 26, 2004 at 01:41:45PM -0400, Pierre A. Humblet wrote: >On Sat, Jun 26, 2004 at 01:09:40PM -0400, Christopher Faylor wrote: >> On Sat, Jun 26, 2004 at 12:05:54PM -0400, Pierre A. Humblet wrote: >> >Beware, I found this: >> >2000-05-19 DJ Delorie >> > * libc/include/stdio.h: no getc/putc macros for cygwin; causes >> > compatibility issues with different dll versions >> >so you may need to recompile when updating cygwin. >> >> Also wouldn't that work around the file locks that were ostensibly put >> there for a reason? > >That crossed my mind. But there is no file lock in the macro, which is >used by systems other than cygwin. How do they manage it? >I also assume that single threaded programs don't need the lock. > >I would be perfectly happy to have a thread-unsafe getc/putc macro, >and to use fgetc/fputc when I care about multithreading. > >Digging deeper, I see there is a function getc_unlocked. Using it >instead of getc improves the speed by a factor 5. >Now that I know about it, I will redefine getc to getc_unlocked when >porting single threaded applications. > >That issue may be a factor in the legendary slowness of Cygwin. FWIW, I added some code to this particular locking function to avoid doing any locks if there is only one thread. I'm generating a snapshot now. It will be interesting to see if it improves things. I didn't do any benchmarking. I just verified that it worked the way I thought it should by looking at strace output. In the process of debugging this, I found that the version of cygwin that I'd been building was not using any of the cygwin override functions as are required for locking. So, my personal cygwin was already pretty fast -- at the expense of thread safety. I'm going to be submitting a patch to newlib to fix this problem. So, please give today's snapshot a try. I just uploaded a new one a couple of minutes ago. http://cygwin.com/snapshots.html cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/