headers
Sameer Agarwal | 1 Mar 2009 03:23
Favicon

maximum number of concurrent network connections

Hello,
I am trying to write a asynchronous server using python's 
asyncore/asynchat library and running it under cygwin. It runs perfectly 
for upto 353 concurrent hosts connected to it, but is unable to connect to 
anymore hosts trying to connect to it.

Is there a limit on the number of concurrent sockets an application can 
have open? Am I hitting that limit, and if so is there a way of modifying 
this limit.

This is on server 2008 with cygwin 1.7.  I am happy to provide any other 
diagnostic information as needed.

Thank you,
Sameer
Permalink | Reply | 0 comments |
headers
Corinna Vinschen | 1 Mar 2009 10:47
Favicon

Re: [1.7] rebaseall doesn't solve the problem

On Feb 28 16:30, Charles Wilson wrote:
> Corinna Vinschen wrote:
> > Only exes require the TS-aware bit.  Two interesting snippets from MSDN:
> > 
> > http://msdn.microsoft.com/en-us/library/cc834995(VS.85).aspx
> 
> But in order to set this flag without problems cropping up, you must
> satisfy:
> 
> * The application does not run as a system service (that is, LUID=System).
> 
> This probably isn't an issue for cygwin-1.7 and beyond, given the
> changes in how services are installed. (Dang, I need to release an
> updated csih...)

I don't think you will get problems even if you're running a Cygwin
application as system service.  I don't know the exact reason for this
rule, but all the TS-aware rules usually have something to do with
"don't change anything which might break the same application running in
another user context."  These rules don't have POSIX applications in
mind.

> * The application does not write to the HKEY Local Machine registry hive
> for user specific data or configuration.
> 
> Hmm.  regtool? /proc/registry?

Hmm, regedit?

You're taking these rules too literally, imho.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Corinna Vinschen | 1 Mar 2009 11:05
Favicon

Re: [1.7] rebaseall doesn't solve the problem

On Mar  1 10:47, Corinna Vinschen wrote:
> On Feb 28 16:30, Charles Wilson wrote:
> > * The application does not write to the HKEY Local Machine registry hive
> > for user specific data or configuration.

Oh, btw., did you read the above closly?  "not write ... HKLM ... user
specific".  We don't do that.  We don't use HKLM for user specific
data or configuration.  Only for system-wide data or configuration.

> > Hmm.  regtool? /proc/registry?
> 
> Hmm, regedit?

Which is to say, you can't use that rule on tools which are designed
to manipulate the registry in general.

Corinna

--

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat
Permalink | Reply | 0 comments |
headers
Corinna Vinschen | 1 Mar 2009 11:20
Favicon

Re: [1.7] rebaseall doesn't solve the problem

On Feb 28 16:18, Charles Wilson wrote:
> Corinna Vinschen wrote:
> > Uh, ok.  In that case, yes, it needs some tweaking.  Actually, maybe
> > the tool should really be named differently.  Something suggesting
> > that it in general changes Win32-related PE/COFF header flags.  ASLR
> > and TS-aware are just some of them, in theory.
> 
> I'm open to suggestions.  "peimgflags"?  Currently, aslr only

peflags?

> > I have to test if the TS-aware flag makes any difference on
> > a 2K8 TS machine anyway.  I think (and hope) that this flag will
> > persuade tsappcmp.dll into igoring an executable instead of scrambling
> > its page executable protection flags.  If so, we should really set this
> > flag in all applications.  Well, not that I gave up the idea that
> > Microsoft should fix that bug in tsappcmp.dll in the first place...
> 
> Ha!

Can you tweak the tool so I can test that next week?

> Or a separate aslrall (peimgflags(?)_all) script...it would share a lot
>  of code with rebaseall, but it's not really all THAT big a script.  The
> reason I didn't do that originally was I wanted to reuse the same
> (generated) filelist in each case.  But, it seems that the flexibility
> in having aslrall(?) make its own file list -- which may include exe's
> as well as dll's -- is more important.

+1
(Continue reading)

Permalink | Reply | 16 comments |
headers
Mike Marchywka | 1 Mar 2009 15:22
Picon
Favicon

console scroll speed on Win XP


Hi,

I just got done setting up cygwin on an XP laptop.
Previously, I had set it up on a couple of 2k machines and one other XP desktop.
The XP  console scroll rate seems to be intolerably slow only on the XP machines. I thought it
may be due to cygwin but even a DOS window scrolling seems slow. 
It scrolls by slowly trying to do a "dir" and maxes out my 1.8Ghz CPU.

Is there some option to turn off to make this reasonable or has anyone
else seen this problem? I set display options to maximize performance 
and there don't seem to be any options available for the cygwin window
that would help.

I noted that some previously slow to render html does display more
quickly on my new XP install than on 2k but I can' imagine how you can
max out a>1 Ghz CPU scrolling text in a small window.

Has anyone else noticed this? 

Thanks.

Mike Marchywka 

_________________________________________________________________
Windows Live™: Life without walls.
http://windowslive.com/explore?ocid=TXT_TAGLM_WL_allup_1a_explore_032009
Permalink | Reply | 5 comments |
headers
Andy Koppe | 1 Mar 2009 21:34
Picon

Re: console scroll speed on Win XP

> Is there some option to turn off to make this reasonable or has anyone
> else seen this problem? I set display options to maximize performance
> and there don't seem to be any options available for the cygwin window
> that would help.

Yep, the Windows console is slow alright, and I don't know of any way
to speed it up. What I can recommend are the alternative terminal
emulators available in Cygwin: xterm, rxvt, and the recently added
mintty (by yours truly), all of which scroll a lot faster than the
console.

(Please note that all three share one drawback though: native Windows
console programs might not work correctly in them, particularly
input.)

Andy
Permalink | Reply | 4 comments |
headers
Dave Korn | 1 Mar 2009 21:45

Re: console scroll speed on Win XP

Andy Koppe wrote:
>> Is there some option to turn off to make this reasonable or has anyone
>> else seen this problem? I set display options to maximize performance
>> and there don't seem to be any options available for the cygwin window
>> that would help.
> 
> Yep, the Windows console is slow alright, and I don't know of any way
> to speed it up. 

  Minimising it works a treat!

    cheers,
      DaveK
Permalink | Reply | 0 comments |
headers
Mike Marchywka | 1 Mar 2009 21:54
Picon
Favicon

RE: console scroll speed on Win XP


----------------------------------------
> Date: Sun, 1 Mar 2009 20:34:33 +0000
> Subject: Re: console scroll speed on Win XP
> From: andy.koppe <at> gmail.com
> To: cygwin <at> cygwin.com
>
>> Is there some option to turn off to make this reasonable or has anyone
>> else seen this problem? I set display options to maximize performance
>> and there don't seem to be any options available for the cygwin window
>> that would help.
>
> Yep, the Windows console is slow alright, and I don't know of any way
> to speed it up. What I can recommend are the alternative terminal
> emulators available in Cygwin: xterm, rxvt, and the recently added
> mintty (by yours truly), all of which scroll a lot faster than the
> console.
>
> (Please note that all three share one drawback though: native Windows
> console programs might not work correctly in them, particularly
> input.)
>

ROFL- so an emulator with a bunch of extra layers of emulation
calls is beating the MSFT DOS window? I don't think right now
the cygwin window is slowed than say a DIR listing in native 
thing. How can you wreck text scrolling? 

What is wrong with the native apps ? I use them in some scripts
but usually not interactively. I don't normally care about text
(Continue reading)

Permalink | Reply | 2 comments |
headers
Aaron Gray | 1 Mar 2009 22:18

Fw: patch command giving permission denied

On Sat, Feb 28, 2009 at 1:30 AM, Aaron Gray 
<aaronngray.lists <at> googlemail.com> wrote:
>I am getting the following on executing the patch command :-
>
>  bash: /usr/bin/patch: Permission Denied
>
>It works on my other Vista machine okay (That is an Enterprise one rather 
>than a Home version)
>
>Anyone got any ideas why and how to fix it

It works fine on my other Vista Home machine.

It works okay if I run cygwin bash as an administrator.

Why is this machine behaving differently and how do I fix it ?

I tried reloading Cygwin from scratch, but that did not help.

Aaron
Permalink | Reply | 501 comments |
headers
Matt Wozniski | 1 Mar 2009 22:35
Picon

Re: console scroll speed on Win XP

On Sun, Mar 1, 2009 at 3:54 PM, Mike Marchywka wrote:
>>
>>> Is there some option to turn off to make this reasonable or has anyone
>>> else seen this problem? I set display options to maximize performance
>>> and there don't seem to be any options available for the cygwin window
>>> that would help.
>>
>> Yep, the Windows console is slow alright, and I don't know of any way
>> to speed it up. What I can recommend are the alternative terminal
>> emulators available in Cygwin: xterm, rxvt, and the recently added
>> mintty (by yours truly), all of which scroll a lot faster than the
>> console.
>>
>> (Please note that all three share one drawback though: native Windows
>> console programs might not work correctly in them, particularly
>> input.)
>
> What is wrong with the native apps ? I use them in some scripts
> but usually not interactively. I don't normally care about text
> formatting if output is just a bit different.

IO buffering won't work the way they expect when they don't have a
real console.  So, you wind up with weird conditions like the program
waiting for input after printing out a prompt - but the app didn't
call fflush(), so the prompt hasn't actually been displayed, but it's
still waiting for you to answer the question.  Using them in a
scripted way should work fine, it's just interactive usage that you
would expect to be broken.

~Matt
(Continue reading)

Permalink | Reply | 1 comment |

Gmane