Re: I have user mounts instead of system ones.

[fergus]

>> mount -u -b --change-cygdrive-prefix "/cygdrive"
>> What do I do to get rid of this user mount, please? 

Try

umount -uc

I think -uc will be sufficient for the cygdrive-prefix; the switch -uA would
get rid of _all_ user mounts, and you don't seem to have any left? HTH.

Fergus


--
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/

/home dir missing

[prashanthu baragur]

Hi,

Am a newbie to cygwin. Am trying to install cygwin as per the
procedure in the web.

http://cplus.about.com/od/compilersandides/l/aa061204a.htm

After installation i observe that the /home directory is missing.
Other that this things are normal. I have logged into my system as a
local user  in our company domain.Where am i going wrong ?

Please reply.
Prashanth

--
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/

Re: Serious performance problems (malloc related?)

[Linda W]

One area that I've noticed slowness is in using the 'find' command
to search for old "tmp" files or to rebuild the locate database.

In tracing the Win32 file operations, find seems to perform multiple
file open operations for each file processed.  One way to speed up
operations in this area might be to keep a "cache" of the last "N"
file handles.  I suspect it's just the Windows path lookup mechanism
being slow to reopen things.  But if the cygwin.dll could cache even
the past 5 entries, it might speed things up significantly.  If it
is opened each time to read different information, it might be much
cheaper to collect all the information at one time and cache it in
an internal "inode cache" that could expire in a second or so. 


If it would "slow" down other programs, it could have some smarts in
the system calls to look for calling patterns from programs like find
that need a couple or more openings to fully "process a file", that all
happen within a few milliseconds of each other.

BTW -- in case anyone is interested -- you can use the free Unix Services
for windows available for WinXP.  However, amusingling enough -- their
execution times are *slower* than cygwin's...  Of course MS might have 
deliberately used non-optimized methods for their services to convince

people to recode for the Win32 interface (and thus benefit by increased
Win32 lockin).

linda


Christopher Faylor wrote:


Yep.  This is pretty much what I expected.  Now we'll see a stream of
people commenting on slowness and speculating on the cause without
spending any time to actually figure out what the cause might be.
 


Think of what a hero you'll be if you figure out a way to improve
cygwin's "slowness".

 



--
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/

Re: /home dir missing

[Richard Copley]

On 02/06/05, prashanthu baragur <[EMAIL PROTECTED]> wrote:
> Hi,
> 
> Am a newbie to cygwin. Am trying to install cygwin as per the
> procedure in the web.
> 
> http://cplus.about.com/od/compilersandides/l/aa061204a.htm

Wow, seven pages of installation instructions. Couldn't he have just
said 'follow the on-screen prompts'?

> After installation i observe that the /home directory is missing.
> Other that this things are normal. I have logged into my system as a
> local user  in our company domain.Where am i going wrong ?

The home directory should be created the first time you open a bash
login shell, by the shell script /etc/profile. Thereafter bash always
starts there. Have you clicked on "Cygwin Bash Shell" on your Start
Menu?

Good luck.
Richard

--
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/

RE: /home dir missing

[Dave Korn]

Original Message
>From: prashanthu baragur
>Sent: 02 June 2005 08:06

> Hi,
> 
> Am a newbie to cygwin. Am trying to install cygwin as per the
> procedure in the web.
> 
> http://cplus.about.com/od/compilersandides/l/aa061204a.htm
> 
> After installation i observe that the /home directory is missing.
> Other that this things are normal. I have logged into my system as a
> local user  in our company domain.Where am i going wrong ?
> 
> Please reply.
> Prashanth


  Did you run "mkpasswd -l -d >/etc/passwd" and "mkgroup -l -d >/etc/group"
yet?



cheers,
  DaveK
-- 
Can't think of a witty .sigline today


--
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/

RE: OLOCA

[Dave Korn]

Original Message
>From: Igor Pechtchanski
>Sent: 31 May 2005 20:34

> On Tue, 31 May 2005, Christopher Faylor wrote:
> 
>> On Tue, May 31, 2005 at 02:08:22PM -0400, Igor Pechtchanski wrote:
>>> On Tue, 31 May 2005, Dave Korn wrote:
>>> 
 Original Message
> From: Igor Pechtchanski
> Sent: 31 May 2005 18:44
 
> Quoting from the bottom of the OLOCA:
 
   Maybe you should move that bit up to the top?
>>> 
>>> I doubt it matters where it is.  That's the only place on the page that
>>> says to send suggestions to the main Cygwin list.  The words *on one of
>>> the Cygwin lists* are *in the same sentense*.  That should suffice, no?
>>> :-) 
>>> 
   And perhaps you should make the "*on one of the Cygwin lists*" text a
 bit bigger and more eye-catching.
 
   Like about 36 miles on a side and bright pink and flashing, for
 instance.
>>> 
>>> I'll leave that to script kiddies.  A couple more inquiries like that,
>>> though, and I'll consider making that bit bold...
>> 
>> I think we need an acronym to describe the problem:
>> 
>> Only Acronyms Used In Cygwin Lists
>> 
>> OAUICL
> 
> Agreed, except that "Only Acronyms Used In The Cygwin Lists Should Be
> Suggested" lends itself better to prononciation:
> 
> OAUTICLSBS
> 
> (Wow tickles bs)...  Comments?


  How about OSCA:  Only Specifically Cygwin Acronyms  ?


cheers,
  DaveK
-- 
Can't think of a witty .sigline today


--
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/

Re: /home dir missing

[prashanthu baragur]

Dave,

I did not ran 

mkpasswd -l -d >/etc/passwd" and "mkgroup -l -d >/etc/group"

Since i did "mkdir /home", /home is just like "/temp" directory.

Any care to be taken during cygwin installation  ??

Thanks
Prashanth




On 6/2/05, Dave Korn <[EMAIL PROTECTED]> wrote:
> Original Message
> >From: prashanthu baragur
> >Sent: 02 June 2005 08:06
> 
> > Hi,
> >
> > Am a newbie to cygwin. Am trying to install cygwin as per the
> > procedure in the web.
> >
> > http://cplus.about.com/od/compilersandides/l/aa061204a.htm
> >
> > After installation i observe that the /home directory is missing.
> > Other that this things are normal. I have logged into my system as a
> > local user  in our company domain.Where am i going wrong ?
> >
> > Please reply.
> > Prashanth
> 
> 
>  Did you run "mkpasswd -l -d >/etc/passwd" and "mkgroup -l -d >/etc/group"
> yet?
> 
> 
> 
>cheers,
>  DaveK
> --
> Can't think of a witty .sigline today
> 
> 
> --
> 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/
> 
>

--
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/

new vs malloc, -fno-exception - Re: Serious performance problems (malloc related?)

[Axel Naumann]

Hi,

here's a little study, allocating / freeing mem in a loop, once with the
C malloc/free, once (-DUSE_CXX_HEAP) using new/delete. It reproduces the
factor ~3 for gcc cygwin.

I've built it with MSVC's cl 7.0, gcc 3.3.3, with and without
-mno-cygwin, using the cygwin-inst snapshot from 20050528, cygwin update
from today, on a P4 1.8GHz, 512MB RAM, XPSP2 Prof.

Result: the user fraction with "new" is 3 times the user fraction with
"malloc". mingw and MSVC show no measurable difference.[1][2]

cl -nologo :
real0m3.094s
user0m0.030s
sys 0m0.016s
g++ -mno-cygwin :
real0m3.733s
user0m0.031s
sys 0m0.000s
g++ :
real0m4.226s
user0m2.358s
sys 0m1.796s
cl -nologo -DUSE_CXX_HEAP:
real0m3.114s
user0m0.015s
sys 0m0.015s
g++ -mno-cygwin -DUSE_CXX_HEAP:
real0m3.811s
user0m0.015s
sys 0m0.015s
g++ -DUSE_CXX_HEAP:
real0m8.779s
user0m7.030s
sys 0m1.671s

To reproduce run make.

NOTE: -fno-exceptions has no measurable impact on the results.

Hope that helps, otherwise just ignore it (well - there no need to say
that on cygwin-ml, I suppose :-)

Axel.

NB: the reason I care is because we see the same performance hit (since
a few months) in the cygwin port of the _open_source_ program ROOT
(root.cern.ch).

[1]: The binary is run twice to make sure that the win cache is in the
same state for all combinations. (Disabling the cache might be of
academical interest. It's not real-world, real-use compatible, though.)

[2]: The sys fraction is considerably higher (O(100)) for gcc compared
with mingw/cl. I realize this is somewhat expected - but the amount is
astonishing to me nevertheless. Anyway - that's for later.
#if USE_CXX_HEAP
#include 
#define malloc(SIZE) new char[SIZE] 
#define free(POS) delete[] POS
#else
#include 
#endif

int main(int argc, char* argv[]) {
   const size_t size=1000;
   const long int loop0=10;
   const long int loop1=10;
   char *ptr[loop1];
   int i0=0;
   int i1=0;

   for(;i0OUTFILE:=check_cyg_mem.out
all: 
rm -f $(OUTFILE)
$(MAKE) builds
USE_CXX_HEAP=-DUSE_CXX_HEAP $(MAKE) builds
cat $(OUTFILE)
builds:
CXX="cl -nologo" $(MAKE) run
CXX="g++ -mno-cygwin" $(MAKE) run
CXX=g++ $(MAKE) run
run:
@$(CXX) $(USE_CXX_HEAP) check_cyg_mem.cxx -o check_cyg_mem.exe \
&& ./check_cyg_mem.exe \
&& echo -n "$(CXX) $(USE_CXX_HEAP): " >> $(OUTFILE) \
&& bash -c "time ./check_cyg_mem.exe" >> $(OUTFILE) 2>&1

.phony: all builds run

--
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/

RE: OLOCA

[Karl M]

From: "Dave Korn"
Subject: RE: OLOCA
Date: Thu, 2 Jun 2005 14:19:15 +0100

Original Message
>From: Igor Pechtchanski
>Sent: 31 May 2005 20:34

> On Tue, 31 May 2005, Christopher Faylor wrote:
>
>> On Tue, May 31, 2005 at 02:08:22PM -0400, Igor Pechtchanski wrote:
>>> On Tue, 31 May 2005, Dave Korn wrote:
>>>
 Original Message
> From: Igor Pechtchanski
> Sent: 31 May 2005 18:44

> Quoting from the bottom of the OLOCA:

   Maybe you should move that bit up to the top?
>>>
>>> I doubt it matters where it is.  That's the only place on the page 
that
>>> says to send suggestions to the main Cygwin list.  The words *on one 
of
>>> the Cygwin lists* are *in the same sentense*.  That should suffice, 
no?

>>> :-)
>>>
   And perhaps you should make the "*on one of the Cygwin lists*" text 
a

 bit bigger and more eye-catching.

   Like about 36 miles on a side and bright pink and flashing, for
 instance.
>>>
>>> I'll leave that to script kiddies.  A couple more inquiries like that,
>>> though, and I'll consider making that bit bold...
>>
>> I think we need an acronym to describe the problem:
>>
>> Only Acronyms Used In Cygwin Lists
>>
>> OAUICL
>
> Agreed, except that "Only Acronyms Used In The Cygwin Lists Should Be
> Suggested" lends itself better to prononciation:
>
> OAUTICLSBS
>
> (Wow tickles bs)...  Comments?


  How about OSCA:  Only Specifically Cygwin Acronyms  ?

And then once each year, we can have a big awards dinner in Boston for the 
best acronyms in each of several categories.


Wow, the Cygwin night at the OSCAs.



--
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/

Re: I have user mounts instead of system ones.

[Jason FU]

  bonhard.uklinux.net> writes:

> 
> >> mount -u -b --change-cygdrive-prefix "/cygdrive"
> >> What do I do to get rid of this user mount, please? 
> 

Thanks! I've got rid of all user mount on my Windows Server 2003 but I still
have the same problem of having the services up.

Thanks!

Regards,

Jason


--
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/

Re: Serious performance problems (malloc related?)

[Sunil]

> amusingling enough -- their
> execution times are *slower* than cygwin's...  Of

this is a joke right? I found SFU to be at least 2-3
times faster in loading and executing programs in
general. Its too bad their POSIX imple. is less than
half baked and unuseable for building any package
OOTB.

> course MS might have 
> deliberately used non-optimized methods for their
> services to convince
> people to recode for the Win32 interface (and thus
> benefit by increased
> Win32 lockin).

this might be famously true.

-Sunil



__ 
Discover Yahoo! 
Find restaurants, movies, travel and more fun for the weekend. Check it out! 
http://discover.yahoo.com/weekend.html 


--
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/

Re: /home dir missing

[Thorsten Kampe]

On Thu, 2 Jun 2005 12:27:45 +, Richard Copley wrote:
> On 02/06/05, prashanthu baragur <[EMAIL PROTECTED]> wrote:
>> Hi,
>> 
>> Am a newbie to cygwin. Am trying to install cygwin as per the
>> procedure in the web.
>> 
>> http://cplus.about.com/od/compilersandides/l/aa061204a.htm
> 
> Wow, seven pages of installation instructions. Couldn't he have just
> said 'follow the on-screen prompts'?

*chuckle*

That's /exactly/ what I thought, too. Or even "klick on 'Next' until
the window goes away and then click on the link on the desktop".


--
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/

RE: OLOCA

[Igor Pechtchanski]

On Thu, 2 Jun 2005, Karl M wrote:

> > From: "Dave Korn"
> > Subject: RE: OLOCA
> > Date: Thu, 2 Jun 2005 14:19:15 +0100
> >
> > Original Message
> > >From: Igor Pechtchanski
> > >Sent: 31 May 2005 20:34
> >
> > > On Tue, 31 May 2005, Christopher Faylor wrote:
> > >
> > >> On Tue, May 31, 2005 at 02:08:22PM -0400, Igor Pechtchanski wrote:
> > >>> On Tue, 31 May 2005, Dave Korn wrote:
> > >>>
> >  Original Message
> > > From: Igor Pechtchanski
> > > Sent: 31 May 2005 18:44
> > 
> > > Quoting from the bottom of the OLOCA:
> > 
> >    Maybe you should move that bit up to the top?
> > >>>
> > >>> I doubt it matters where it is.  That's the only place on the page that
> > >>> says to send suggestions to the main Cygwin list.  The words *on one of
> > >>> the Cygwin lists* are *in the same sentense*.  That should suffice, no?
> > >>> :-)
> > >>>
> >    And perhaps you should make the "*on one of the Cygwin lists*" text a
> >  bit bigger and more eye-catching.
> > 
> >    Like about 36 miles on a side and bright pink and flashing, for
> >  instance.
> > >>>
> > >>> I'll leave that to script kiddies.  A couple more inquiries like that,
> > >>> though, and I'll consider making that bit bold...
> > >>
> > >> I think we need an acronym to describe the problem:
> > >>
> > >> Only Acronyms Used In Cygwin Lists
> > >>
> > >> OAUICL
> > >
> > > Agreed, except that "Only Acronyms Used In The Cygwin Lists Should Be
> > > Suggested" lends itself better to prononciation:
> > >
> > > OAUTICLSBS
> > >
> > > (Wow tickles bs)...  Comments?
> >
> >   How about OSCA:  Only Specifically Cygwin Acronyms  ?
>
> And then once each year, we can have a big awards dinner in Boston for the
> best acronyms in each of several categories.
>
> Wow, the Cygwin night at the OSCAs.

Another meeting interrupted by a loud snort. :-)
Ok, .
Igor
-- 
http://cs.nyu.edu/~pechtcha/
  |\  _,,,---,,_[EMAIL PROTECTED]
ZZZzz /,`.-'`'-.  ;-;;,_[EMAIL PROTECTED]
 |,4-  ) )-,_. ,\ (  `'-'   Igor Pechtchanski, Ph.D.
'---''(_/--'  `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

"The Sun will pass between the Earth and the Moon tonight for a total
Lunar eclipse..." -- WCBS Radio Newsbrief, Oct 27 2004, 12:01 pm EDT

--
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/

Re: Serious performance problems (malloc related?)

[Igor Pechtchanski]

On Thu, 2 Jun 2005, Linda W wrote:

> In tracing the Win32 file operations, find seems to perform multiple
> file open operations for each file processed.  One way to speed up
> operations in this area might be to keep a "cache" of the last "N"
> file handles.  I suspect it's just the Windows path lookup mechanism
> being slow to reopen things.  But if the cygwin.dll could cache even
> the past 5 entries, it might speed things up significantly.  If it
> is opened each time to read different information, it might be much
> cheaper to collect all the information at one time and cache it in
> an internal "inode cache" that could expire in a second or so.
> If it would "slow" down other programs, it could have some smarts in
> the system calls to look for calling patterns from programs like find
> that need a couple or more openings to fully "process a file", that all
> happen within a few milliseconds of each other.

.  .
Igor
-- 
http://cs.nyu.edu/~pechtcha/
  |\  _,,,---,,_[EMAIL PROTECTED]
ZZZzz /,`.-'`'-.  ;-;;,_[EMAIL PROTECTED]
 |,4-  ) )-,_. ,\ (  `'-'   Igor Pechtchanski, Ph.D.
'---''(_/--'  `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

"The Sun will pass between the Earth and the Moon tonight for a total
Lunar eclipse..." -- WCBS Radio Newsbrief, Oct 27 2004, 12:01 pm EDT

--
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/

Re: Serious performance problems (malloc related?)

[Igor Pechtchanski]

On Thu, 2 Jun 2005, Sunil wrote:

> > amusingling enough -- their
> > execution times are *slower* than cygwin's...  Of
>
> this is a joke right? I found SFU to be at least 2-3
> times faster in loading and executing programs in
> general. Its too bad their POSIX imple. is less than
> half baked and unuseable for building any package
> OOTB.

Any favorable mention of SFU on this list had better be a joke. :-)
Igor
-- 
http://cs.nyu.edu/~pechtcha/
  |\  _,,,---,,_[EMAIL PROTECTED]
ZZZzz /,`.-'`'-.  ;-;;,_[EMAIL PROTECTED]
 |,4-  ) )-,_. ,\ (  `'-'   Igor Pechtchanski, Ph.D.
'---''(_/--'  `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

"The Sun will pass between the Earth and the Moon tonight for a total
Lunar eclipse..." -- WCBS Radio Newsbrief, Oct 27 2004, 12:01 pm EDT

--
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/

Re: OLOCA (gold stars, please)

[Christopher Faylor]

On Thu, Jun 02, 2005 at 01:01:22PM -0400, Igor Pechtchanski wrote:
>On Thu, Jun 02, 2005 at 06:57:25AM -0700, Karl M wrote:
>>On Thu, Jun 02, 2005 at 02:19:15PM +0100, Dave Korn wrote:
>>>  How about OSCA:  Only Specifically Cygwin Acronyms  ?
>>
>>And then once each year, we can have a big awards dinner in Boston for the 
>>best acronyms in each of several categories.
>>
>>Wow, the Cygwin night at the OSCAs.
>
>Another meeting interrupted by a loud snort. :-)

Yep.  This caused a "dog invesitgation event" for me.  He generally
wanders in when I emit some sort of loud exclamation.  It's nice when
that happens because I'm laughing rather than snorting in disbelief.

>Ok, .

I think the acronym suggestion and Karl's pun/observation both rate gold
stars.

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/

RE: Serious performance problems (malloc related?)

[Dave Korn]

Original Message
>From: Igor Pechtchanski
>Sent: 02 June 2005 18:08

> On Thu, 2 Jun 2005, Sunil wrote:
> 
>>> amusingling enough -- their
>>> execution times are *slower* than cygwin's...  Of
>> 
>> this is a joke right? I found SFU to be at least 2-3
>> times faster in loading and executing programs in
>> general. Its too bad their POSIX imple. is less than
>> half baked and unuseable for building any package
>> OOTB.
> 
> Any favorable mention of SFU on this list had better be a joke. :-)
>   Igor
> --


  ... or had better have a 'T' between the 'S' and the 'U'!

   :)


cheers,
  DaveK
-- 
Can't think of a witty .sigline today


--
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/

Re: Serious performance problems (malloc related?)

[Christopher Faylor]

On Thu, Jun 02, 2005 at 01:02:30PM -0400, Igor Pechtchanski wrote:
>On Thu, 2 Jun 2005, Linda W wrote:
>>In tracing the Win32 file operations, find seems to perform multiple
>>file open operations for each file processed.  One way to speed up
>>operations in this area might be to keep a "cache" of the last "N" file
>>handles.  I suspect it's just the Windows path lookup mechanism being
>>slow to reopen things.  But if the cygwin.dll could cache even the past
>>5 entries, it might speed things up significantly.  If it is opened
>>each time to read different information, it might be much cheaper to
>>collect all the information at one time and cache it in an internal
>>"inode cache" that could expire in a second or so.  If it would "slow"
>>down other programs, it could have some smarts in the system calls to
>>look for calling patterns from programs like find that need a couple or
>>more openings to fully "process a file", that all happen within a few
>>milliseconds of each other.
>
>.
>.

Oddly enough, Corinna and I have been discussing the possibility of
caching opendir/readdir data for subsequent use in stat().  She's for it
and I'm mildly agin' it.

I think that introducing caching opens the door to all sorts of subtle
race conditions since only the OS can maintain cache coherency.

She thinks that the benefits would outweigh the tiny possibility of bad
cache data resulting from something like performing an "ls" on a file
and having, e.g., some other process sneak in, remove the file and
introduce a directory, but still having "ls" report file data.

There are, of course, other more serious races possible as soon as you
introduce user mode caching of file data...

I thought I should mention this in the off chance that Corinna actually
does implement something just so that history records that this is
something that Corinna has been considering for a while.

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/

Re: Emacs problem with Cygwin 1.5.17-1

[Angelo Graziosi]

On Wed, 1 Jun 2005 19:09:35 -0400 , Christopher Faylor  wrote:

>Please stop doing this.  I do read email.  I will read your email
>when I have time.  Pinging me is not going to help.

You should at least answer "OK. the problem is under investigation" or
something else.

angelo.


--
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/

pthread.h small problem

[Yuval Turgeman]

Hi,
The pthread_cleanup_push and pthread_cleanup_pop macros seems to be
broken in the CVS (misplaced brackets).  I hope I'm not posting to the
wrong list, but here's the patch...

--- ./winsup/cygwin/include/pthread.h.orig  2005-06-02
20:34:00.0 +0300
+++ ./winsup/cygwin/include/pthread.h   2005-06-02 20:34:59.0 +0300
@@ -118,8 +118,9 @@
 
 #define pthread_cleanup_push(_fn, _arg) { __pthread_cleanup_handler
__cleanup_handler = \
 { _fn, _arg, NULL }; \
-_pthread_cleanup_push(
&__cleanup_handler );
-#define pthread_cleanup_pop(_execute) _pthread_cleanup_pop( _execute ); }
+_pthread_cleanup_push(
&__cleanup_handler ); }
+
+#define pthread_cleanup_pop(_execute) _pthread_cleanup_pop( _execute );
 
 /* Condition variables */
 int pthread_cond_broadcast (pthread_cond_t *);


-- 
Yuval Turgeman

--
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/

Re: OLOCA (gold stars, please)

[Igor Pechtchanski]

On Thu, 2 Jun 2005, Christopher Faylor wrote:

> On Thu, Jun 02, 2005 at 01:01:22PM -0400, Igor Pechtchanski wrote:
> >On Thu, Jun 02, 2005 at 06:57:25AM -0700, Karl M wrote:
> >>On Thu, Jun 02, 2005 at 02:19:15PM +0100, Dave Korn wrote:
> >>>  How about OSCA:  Only Specifically Cygwin Acronyms  ?
> >>
> >>And then once each year, we can have a big awards dinner in Boston for
> >>the best acronyms in each of several categories.
> >>
> >>Wow, the Cygwin night at the OSCAs.
> >
> >Ok, .
>
> I think the acronym suggestion and Karl's pun/observation both rate gold
> stars.

You're determined to make me work for it, aren't you? :-)
Done.
Igor
-- 
http://cs.nyu.edu/~pechtcha/
  |\  _,,,---,,_[EMAIL PROTECTED]
ZZZzz /,`.-'`'-.  ;-;;,_[EMAIL PROTECTED]
 |,4-  ) )-,_. ,\ (  `'-'   Igor Pechtchanski, Ph.D.
'---''(_/--'  `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

"The Sun will pass between the Earth and the Moon tonight for a total
Lunar eclipse..." -- WCBS Radio Newsbrief, Oct 27 2004, 12:01 pm EDT

--
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/

Re: Serious performance problems (malloc related?)

[Sunil]

> Any favorable mention of SFU on this list had better
> be a joke. :-)

:)

but can't deny the truth. Seriously, open source on
windows can't do better than what it does(upto the
limits provided by OS) in terms of efficiency. Its
hardly at fault, the thing below it is so darn closed.
Everything on linux is so optimized for exactly the
opposite reason. One reason why I left SFU and became
cygwin was that its closed and I don't know nothing
about what's going on inside. I can even build my own
cygwin1.dll if packaged one lacks a feature because
its not POSIX. Execution speed is one aspect and being
able to build your favourite pkgs easily is another. I
can run something faster only if I can build it...:)

-Sunil
PS: just to give people here a taste of speed
difference:
machine 1: 533Mhz, 10GB 5400rpm disk, 384MB RAM, SFU
on W2K, -> build time for texinfo = 345 seconds.
machine 2: 2400Mhz, 100GB 7200rpm disk, 768MB RAM,
cygwin 1.5.17 on WinXP, -> build time for texinfo =
334 seconds.

build repeated twice to take the caching out of
picture. Please don't bash me, its just a harsh
reality of the closed source. I have chosen cygwin
anyway, so it doesn't matter.



__ 
Discover Yahoo! 
Have fun online with music videos, cool games, IM and more. Check it out! 
http://discover.yahoo.com/online.html

--
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/

Re: OLOCA (gold stars, please)

[Christopher Faylor]

On Thu, Jun 02, 2005 at 02:02:07PM -0400, Igor Pechtchanski wrote:
>On Thu, 2 Jun 2005, Christopher Faylor wrote:
>>On Thu, Jun 02, 2005 at 01:01:22PM -0400, Igor Pechtchanski wrote:
>>>On Thu, Jun 02, 2005 at 06:57:25AM -0700, Karl M wrote:
On Thu, Jun 02, 2005 at 02:19:15PM +0100, Dave Korn wrote:
>  How about OSCA:  Only Specifically Cygwin Acronyms  ?

And then once each year, we can have a big awards dinner in Boston for
the best acronyms in each of several categories.

Wow, the Cygwin night at the OSCAs.
>>>
>>>Ok, .
>>
>>I think the acronym suggestion and Karl's pun/observation both rate gold
>>stars.
>
>You're determined to make me work for it, aren't you? :-)

You know my reputation.

>Done.

Thanks, much appreciated as always.  I'd give you a gold star every time
you take some time out of your day to set up a new gold star for someone
else but somehow I think that would just end up cheapening the whole
gold star process, making gold stars more like yens than dollars.

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/

Re: OLOCA (gold stars, please)

[Igor Pechtchanski]

On Thu, 2 Jun 2005, Christopher Faylor wrote:

> On Thu, Jun 02, 2005 at 02:02:07PM -0400, Igor Pechtchanski wrote:
> >On Thu, 2 Jun 2005, Christopher Faylor wrote:
> >>On Thu, Jun 02, 2005 at 01:01:22PM -0400, Igor Pechtchanski wrote:
> >>>On Thu, Jun 02, 2005 at 06:57:25AM -0700, Karl M wrote:
> On Thu, Jun 02, 2005 at 02:19:15PM +0100, Dave Korn wrote:
> >  How about OSCA:  Only Specifically Cygwin Acronyms  ?
> 
> And then once each year, we can have a big awards dinner in Boston for
> the best acronyms in each of several categories.
> 
> Wow, the Cygwin night at the OSCAs.
> >>>
> >>>Ok, .
> >>
> >>I think the acronym suggestion and Karl's pun/observation both rate gold
> >>stars.
> >
> >You're determined to make me work for it, aren't you? :-)
>
> You know my reputation.

Oh, I don't mind, or I wouldn't've volunteered...

> >Done.
>
> Thanks, much appreciated as always.  I'd give you a gold star every time
> you take some time out of your day to set up a new gold star for someone
> else but somehow I think that would just end up cheapening the whole
> gold star process, making gold stars more like yens than dollars.

Speaking of which, should we put a round holes in our gold stars, to make
them more like 5-yen coins? ;-)
Igor
P.S. How does the OLOCA entry look? :-)
-- 
http://cs.nyu.edu/~pechtcha/
  |\  _,,,---,,_[EMAIL PROTECTED]
ZZZzz /,`.-'`'-.  ;-;;,_[EMAIL PROTECTED]
 |,4-  ) )-,_. ,\ (  `'-'   Igor Pechtchanski, Ph.D.
'---''(_/--'  `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

"The Sun will pass between the Earth and the Moon tonight for a total
Lunar eclipse..." -- WCBS Radio Newsbrief, Oct 27 2004, 12:01 pm EDT

--
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/

Re: pthreads, cygwin and pthread_mutex_lock not blocking

[Peter Rehley]

Here is a patch to thread.cc that allows _lock to process signals.  The 
patch is against the 1.178 version of thread.cc found in cvs.


--- thread.cc.orig  Thu Jun  2 11:17:39 2005
+++ thread.cc   Thu Jun  2 11:20:00 2005
@@ -1543,8 +1543,24 @@
 }
   else
 {
-  WaitForSingleObject (win32_obj_id, INFINITE);
-  set_owner (self);
+  //WaitForSingleObject (win32_obj_id, INFINITE);
+  //set_owner (self);
+  bool loop = true;
+  do
+   switch (pthread::cancelable_wait (win32_obj_id, INFINITE, 
false, true))

+ {
+ case WAIT_OBJECT_0:
+set_owner (self);
+loop=false;
+   break;
+ case WAIT_SIGNALED:
+   _my_tls.call_signal_handler ();
+   break;
+ default:
+   // should never happen
+   return EINVAL;
+ }
+  while (loop);
 }

   return result;

On Jun 1, 2005, at 6:17 PM, Peter Rehley wrote:


Here is the patch to pthread.h

hummingbird:~/MontaVista/tmp prehley$ diff -u pthread.h.cygwin 
pthread.h.new

--- pthread.h.cygwinWed Jun  1 18:15:40 2005
+++ pthread.h.new   Wed Jun  1 18:06:49 2005
@@ -53,12 +53,12 @@
 #define PTHREAD_MUTEX_RECURSIVE 0
 #define PTHREAD_MUTEX_ERRORCHECK 1
 #define PTHREAD_MUTEX_NORMAL 2
-#define PTHREAD_MUTEX_DEFAULT PTHREAD_MUTEX_ERRORCHECK
+#define PTHREAD_MUTEX_DEFAULT PTHREAD_MUTEX_NORMAL
 /* this should be too low to ever be a valid address */
 #define PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP (pthread_mutex_t)18
 #define PTHREAD_NORMAL_MUTEX_INITIALIZER_NP (pthread_mutex_t)19
 #define PTHREAD_ERRORCHECK_MUTEX_INITIALIZER_NP (pthread_mutex_t)20
-#define PTHREAD_MUTEX_INITIALIZER 
PTHREAD_ERRORCHECK_MUTEX_INITIALIZER_NP

+#define PTHREAD_MUTEX_INITIALIZER PTHREAD_NORMAL_MUTEX_INITIALIZER_NP
 #define PTHREAD_ONCE_INIT { PTHREAD_MUTEX_INITIALIZER, 0 }
 #define PTHREAD_PRIO_INHERIT
 #define PTHREAD_PRIO_NONE
@@ -202,4 +202,3 @@
 #endif

 #endif /* _PTHREAD_H */
-

On Jun 1, 2005, at 5:22 PM, Peter Rehley wrote:




On May 31, 2005, at 10:50 AM, David Rothenberger wrote:


On 5/31/2005 10:15 AM, Peter Rehley wrote:
Well, here is a simple test case, but turns out I wasn't using the 
latest version.  I was having the problem on 1.5.12,  I haven't 
been able to get a good build with cygwin 1.5.17-1.  It builds and 
I can run the install script, but when I put the dll in place I see 
the message "cygheap magic number mismatch detected", and gcc 
doesn't want to work.


I had a similar problem (see 
). It turned out 
it was because I was using the latest release of binutils. Try 
rolling back to the previous release.


Ok, I rolled binutils to 20041229, rebuilt and copied the new dll.  
It's having the same issue that I see in 1.5.12.  When I debug the 
program, I see that the signal is being sent, but it doesn't get 
executed.


I've looked at the cygwin code, and I have noticed that the sleep 
(nanosleep) is calling pthread::cancelable_wait, and that will call 
WaitForMultipleObjects.  However, in pthread_mutex::_lock, it's only 
using WaitForSingleObject.  I'm wondering if something like 
WaitForMultipleObjects should be added to the lock function so that 
signals (SIGCHLD, in my case) can be handled.


It's just a guess since I'm not an expert with this code.

Enjoy,
Peter
---
A Møøse once bit my sister


--
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/




Enjoy,
Peter
---
A Møøse once bit my sister


--
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/




Enjoy,
Peter
---
A Møøse once bit my sister


--
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/

Re: Serious performance problems (malloc related?)

[Igor Pechtchanski]

On Thu, 2 Jun 2005, Sunil wrote:

> > Any favorable mention of SFU on this list had better
> > be a joke. :-)
>
> :)
>
> but can't deny the truth. Seriously, open source on
> windows can't do better than what it does(upto the
> limits provided by OS) in terms of efficiency. Its
> hardly at fault, the thing below it is so darn closed.
> Everything on linux is so optimized for exactly the
> opposite reason. One reason why I left SFU and became
> cygwin was that its closed and I don't know nothing
> about what's going on inside. I can even build my own
> cygwin1.dll if packaged one lacks a feature because
> its not POSIX. Execution speed is one aspect and being
> able to build your favourite pkgs easily is another. I
> can run something faster only if I can build it...:)
>
> -Sunil
> PS: just to give people here a taste of speed
> difference:
> machine 1: 533Mhz, 10GB 5400rpm disk, 384MB RAM, SFU
> on W2K, -> build time for texinfo = 345 seconds.
> machine 2: 2400Mhz, 100GB 7200rpm disk, 768MB RAM,
> cygwin 1.5.17 on WinXP, -> build time for texinfo =
> 334 seconds.
>
> build repeated twice to take the caching out of
> picture. Please don't bash me, its just a harsh
> reality of the closed source. I have chosen cygwin
> anyway, so it doesn't matter.

Heh.  Ok, I'll tcsh you.  A determined person (especially one who had
admitted to being able to build the Cygwin DLL from source) would try to
strace or profile the run to see where the bottlenecks are.  Since it's
all open source, you could even contribute performance fixes (or a sound
analysis based on facts, which is usually also appreciated).

Of course, to confirm the facts, one would need to run both experiments on
the same machine first, to make sure there really *is* a performance
difference.
Igor
-- 
http://cs.nyu.edu/~pechtcha/
  |\  _,,,---,,_[EMAIL PROTECTED]
ZZZzz /,`.-'`'-.  ;-;;,_[EMAIL PROTECTED]
 |,4-  ) )-,_. ,\ (  `'-'   Igor Pechtchanski, Ph.D.
'---''(_/--'  `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

"The Sun will pass between the Earth and the Moon tonight for a total
Lunar eclipse..." -- WCBS Radio Newsbrief, Oct 27 2004, 12:01 pm EDT

--
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/

Re: Serious performance problems (malloc related?)

[Christopher Faylor]

On Thu, Jun 02, 2005 at 11:04:40AM -0700, Sunil wrote:
>>Any favorable mention of SFU on this list had better be a joke.  :-)
>
>:)
>
>but can't deny the truth.  Seriously, open source on windows can't do
>better than what it does(upto the limits provided by OS) in terms of
>efficiency.  Its hardly at fault, the thing below it is so darn closed.

Well, just to be devil's advocate, SFU is hardly unique in being a
closed "UNIX" implementation.  If you are going to fault Microsoft
for this then you have to also fault HP, IBM, and (for now) Sun.

The last I knew (and it's been a while since I looked into this), SFU
gets its speed from being a "subsystem" which can use some of the more
low-level things than something like cygwin can.  But, I thought that it
was actually a pretty nice implementation of UNIX, all things
considered.

OTOH, Corinna is hard at work adding low-level Nt* calls to cygwin so,
if it wasn't for the requirement that everything has to work on Windows
9x, the DLL would be smaller and faster.  Instead, every system call
currently needs to have a "do this if it's NT and that if it's 9x" test
so "we" have been slow in moving to bypass the win32 api layer on
Windows NT.

OTOH, we will rebuild it.  We do have the technology.

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/

Re: OLOCA (gold stars, please)

[Christopher Faylor]

On Thu, Jun 02, 2005 at 02:19:51PM -0400, Igor Pechtchanski wrote:
>P.S. How does the OLOCA entry look? :-)

Poifect.

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/

RE: Serious performance problems (malloc related?)

[Robb, Sam]

> OTOH, Corinna is hard at work adding low-level Nt* calls to cygwin so,
> if it wasn't for the requirement that everything has to work 
> on Windows
> 9x, the DLL would be smaller and faster.  Instead, every system call
> currently needs to have a "do this if it's NT and that if 
> it's 9x" test
> so "we" have been slow in moving to bypass the win32 api layer on
> Windows NT.
> 
> OTOH, we will rebuild it.  We do have the technology.

Is there any reason why the cygwin DLL couldn't be built
twice: once for Win9x, and once for WinNT-based systems?

Aside from potential installation issues ("install this
version of the DLL under 9x, that version under NT), it
seems like this would be a reasonable optimization.

-Samrobb


--
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/

RE: Serious performance problems (malloc related?)

[Igor Pechtchanski]

On Thu, 2 Jun 2005, Robb, Sam wrote:

> > OTOH, Corinna is hard at work adding low-level Nt* calls to cygwin so,
> > if it wasn't for the requirement that everything has to work on
> > Windows 9x, the DLL would be smaller and faster.  Instead, every
> > system call currently needs to have a "do this if it's NT and that if
> > it's 9x" test so "we" have been slow in moving to bypass the win32 api
> > layer on Windows NT.
> >
> > OTOH, we will rebuild it.  We do have the technology.
>
> Is there any reason why the cygwin DLL couldn't be built
> twice: once for Win9x, and once for WinNT-based systems?
>
> Aside from potential installation issues ("install this
> version of the DLL under 9x, that version under NT), it
> seems like this would be a reasonable optimization.

As long as we're mulling over ideas...

Alternatively, one could write a helper library that implements Nt*
low-level calls on Win9x (as wrappers around the current Win9x
functionality), and then Cygwin itself would only need to test once
whether it's running on 9x, to load the extra helper code.
Igor
-- 
http://cs.nyu.edu/~pechtcha/
  |\  _,,,---,,_[EMAIL PROTECTED]
ZZZzz /,`.-'`'-.  ;-;;,_[EMAIL PROTECTED]
 |,4-  ) )-,_. ,\ (  `'-'   Igor Pechtchanski, Ph.D.
'---''(_/--'  `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

"The Sun will pass between the Earth and the Moon tonight for a total
Lunar eclipse..." -- WCBS Radio Newsbrief, Oct 27 2004, 12:01 pm EDT

--
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/

Re: Serious performance problems (malloc related?)

[Gerrit P. Haase]

Sunil wrote:


machine 1: 533Mhz, 10GB 5400rpm disk, 384MB RAM, SFU
on W2K, -> build time for texinfo = 345 seconds.
machine 2: 2400Mhz, 100GB 7200rpm disk, 768MB RAM,
cygwin 1.5.17 on WinXP, -> build time for texinfo =
334 seconds.


-> 345 seconds vs. 334 seconds

So actually, cygwin is faster than SFU, isn't it?


Gerrit
--
=^..^=

--
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/

Re: Serious performance problems (malloc related?)

[Christopher Faylor]

On Thu, Jun 02, 2005 at 02:38:06PM -0400, Robb, Sam wrote:
>>OTOH, Corinna is hard at work adding low-level Nt* calls to cygwin so,
>>if it wasn't for the requirement that everything has to work on Windows
>>9x, the DLL would be smaller and faster.  Instead, every system call
>>currently needs to have a "do this if it's NT and that if it's 9x" test
>>so "we" have been slow in moving to bypass the win32 api layer on
>>Windows NT.
>>
>>OTOH, we will rebuild it.  We do have the technology.
>
>Is there any reason why the cygwin DLL couldn't be built twice: once
>for Win9x, and once for WinNT-based systems?

We've thought about doing that.  This introduces its own support burden.
Either you sprinkle the code with ifdefs or you introduce 9x and nt
directories.  It's still a possibility, though.

One thing that I've been moving to is an improvement in cygwin's
autoload functionality so that you could use something like "CreateFile"
in the cygwin code but really use a wrapper for "NtCreateFile" if it was
available.

You could do things the other way around, so that NtCreateFile is used
in the main code which invokes a NtCreateFile wrapper for 9x systems but
I am leery of doing things this way since that means that the only
people capable of writing code for cygwin are the people who understand
Nt* calls.  That is a subset of the already small number of people who
understand the UNIX and Windows APIs well enough to work on Cygwin.

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/

Re: pthread.h small problem

[Shankar Unni]

Yuval Turgeman wrote:

Hi,
The pthread_cleanup_push and pthread_cleanup_pop macros seems to be
broken in the CVS (misplaced brackets).  I hope I'm not posting to the
wrong list, but here's the patch...


I'm pretty sure the braces are placed like that *deliberately*, to force 
you to bracket code with the two macros or get a syntax error.



--
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/

Re: How to install perl modules?

[Yitzchak Scott-Thoennes]

On Wed, Jun 01, 2005 at 09:58:24PM -0700, Linda W wrote:
> FYI -- I discovered the cause of a problem I had in manipulating the
> Registry.  There is a bug in the Win32 Registry manipulation routines.
> Both TieRegistry and the original Registry interface apparently
> use an older interface -- something like (?), libcalls ending with "A"
> where new ones end with "W". The "A" interface was for 8-bit characters.
> The "W" interface works with the 16-bit characters in the registry.
> 
> While it was thought this might have been due to "bogus" registry entries,
> according to the MS registry documentation, the only illegal character
> in a registry "name" is "\". This causes perl to fail when manipulating
> some binary key- & value- names.
> 
> I don't know which other routines still use the older 8-bit character
> calls, but there may be similar problems if they use the older
> interface.  Note that these modules are broken in the ASPN version
> of perl as well.

I'm not sure if you are the same Linda who posted here:

  http://perlmonks.org/index.pl?node_id=456194

but if so, please reread the messages in that thread from Tye, the
maintainer of those modules (other than the obsolete Win32::Registry).

In particular:
  This is not a bug, and the modules are not broken.  It is an
intentional limitation of the win32 *A routines, which
Win32::TieRegistry uses.  It did sound as if he would be open to
patches to *optionally* use *W there.  Doing so by default would
break things for existing users.

  If you need to use the *W api, it is available through
Win32API::Registry, but you need to take care to provide the UCS-16
encoding that *W expects.

--
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/

Re: Serious performance problems (malloc related?)

[René Berber]

Gerrit P. Haase wrote:
> Sunil wrote:
> 
>> machine 1: 533Mhz, 10GB 5400rpm disk, 384MB RAM, SFU
>> on W2K, -> build time for texinfo = 345 seconds.
>> machine 2: 2400Mhz, 100GB 7200rpm disk, 768MB RAM,
>> cygwin 1.5.17 on WinXP, -> build time for texinfo =
>> 334 seconds.
> 
> 
> -> 345 seconds vs. 334 seconds
> 
> So actually, cygwin is faster than SFU, isn't it?

Not really.  It's 334 on a 2.4 GHz P4 vs 345 on a 533 MHz P3.
-- 
René Berber


--
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/

Re: pthread.h small problem

[Christopher Faylor]

On Thu, Jun 02, 2005 at 12:52:56PM -0700, Shankar Unni wrote:
>Yuval Turgeman wrote:
>>Hi,
>>The pthread_cleanup_push and pthread_cleanup_pop macros seems to be
>>broken in the CVS (misplaced brackets).  I hope I'm not posting to the
>>wrong list, but here's the patch...
>
>I'm pretty sure the braces are placed like that *deliberately*, to force 
>you to bracket code with the two macros or get a syntax error.

correct.

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/

Re: Serious performance problems (malloc related?)

[Gerrit P. Haase]

Igor Pechtchanski wrote:


On Thu, 2 Jun 2005, Robb, Sam wrote:

Is there any reason why the cygwin DLL couldn't be built
twice: once for Win9x, and once for WinNT-based systems?

Aside from potential installation issues ("install this
version of the DLL under 9x, that version under NT), it
seems like this would be a reasonable optimization.



As long as we're mulling over ideas...


Alternatively, we could drop Win98 support.


Gerrit
--
=^..^=

--
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/

Re: Emacs problem with Cygwin 1.5.17-1

[Larry Hall]

At 01:37 PM 6/2/2005, you wrote:

>On Wed, 1 Jun 2005 19:09:35 -0400 , Christopher Faylor  wrote:
>
>>Please stop doing this.  I do read email.  I will read your email
>>when I have time.  Pinging me is not going to help.
>
>You should at least answer "OK. the problem is under investigation" or
>something else.

This isn't a customer support line.  It's volunteer.  While most postings to 
this list receive some sort of response at some time, no one is obligated 
to respond to any posts.  If this "policy" proves to be a problem for you,
you, of course, aren't obligated to post on this list.  Also, paid Cygwin
support contracts are available through Red Hat at least.  You may want to 
consider that option if you want quick and consistent response times.




--
Larry Hall  http://www.rfk.com
RFK Partners, Inc.  (508) 893-9779 - RFK Office
838 Washington Street   (508) 893-9889 - FAX
Holliston, MA 01746 


--
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/

strace data seems to show hang during socket close

[Mark Pizzolato]

I trying to debug an aparrent hang problem in clamav's clamd.

Under my test load, I can usually get clamd to hang rather easily.   Today I 
got lucky and managed to get an strace of the hang happening (usually the 
hang doesn't happen while stracing...).  When this app hung, it stopped 
consuming any CPU cycles.


Now, I'm trying to interpret the strace results to get a clue about what 
isn't working right.


When clamd hung, the clamd log file ended with the following lines:

Wed Jun  1 15:57:10 2005 -> stream 1753: OK
Wed Jun  1 16:00:11 2005 -> ERROR: ScanStream 2043: accept timeout.
Wed Jun  1 16:00:14 2005 -> ERROR: ScanStream 1289: accept timeout.

I'm trying to understand why it appears that the two worker threads (0x95C 
and 0x490) seem to have "disappeared" and hung indefinately while attempting 
to close a socket.  Why might this happen?


strace was invoked with: 
strace --pid=3772 --output=clamd.strace --flush-period=30 --mask=all


The end of the strace data contains.

 311 528007410 [unknown (0x948)] clamd 3772 writev: 44 = write (3, 
0x26CC500, 1), errno 90

 247 528007657 [unknown (0x948)] clamd 3772 close: close (11)
1606 528009263 [unknown (0x948)] clamd 3772 fhandler_socket::close: 0 = 
fhandler_socket::close()

 210 528009473 [unknown (0x948)] clamd 3772 close: 0 = close (11)
 409 528009882 [unknown (0x948)] clamd 3772 time: 111731 = time (0)
1068 528010950 [unknown (0x948)] clamd 3772 _cygtls::remove: wait 
0x
 527 528011477 [unknown (0x948)] clamd 3772 _cygtls::remove: removed 
0x26CF0A0 element 6

 228 528011705 [unknown (0x948)] clamd 3772 _cygtls::remove: wait 0x0
26718851 554730556 [select_socket] clamd 3772 thread_socket: Win32 select 
returned 1
 274 554730830 [select_socket] clamd 3772 thread_socket: s 0x102F7C28, 
testing fd 4 ()

 321 554731151 [select_socket] clamd 3772 thread_socket: read_ready
3275 554734426 [main] clamd 3772 select_stuff::wait: woke up.  wait_ret 1. 
verifying

 221 554734647 [main] clamd 3772 select_stuff::wait: gotone 1
 131 554734778 [main] clamd 3772 select_stuff::wait: returning 0
 605 554735383 [main] clamd 3772 select_stuff::cleanup: calling cleanup 
routines
 175 554735558 [main] clamd 3772 socket_cleanup: si 0x10B48140 si->thread 
0x610FFC60
 185 554735743 [main] clamd 3772 socket_cleanup: sent a byte to exitsock 
0x2C4, res 1
 249 554735992 [main] clamd 3772 socket_cleanup: reading a byte from 
exitsock 0x2C4

 528 554736520 [main] clamd 3772 socket_cleanup: recv returned 1
 615 554737135 [main] clamd 3772 socket_cleanup: returning
 133 554737268 [main] clamd 3772 peek_socket: considering handle 0x2F0
 160 554737428 [main] clamd 3772 set_bits: me 0x102F7C28, testing fd 4 ()
 117 554737545 [main] clamd 3772 set_bits: ready 1
 629 554738174 [main] clamd 3772 select_stuff::poll: returning 1
 372 554738546 [main] clamd 3772 select_stuff::cleanup: calling cleanup 
routines
 134 554738680 [main] clamd 3772 select_stuff::~select_stuff: deleting 
select records
 435 554739115 [main] clamd 3772 fdsock: reset socket inheritance since 
winsock2_active 1

 395 554739510 [main] clamd 3772 build_fh_pc: fh 0x61816738
 156 554739666 [main] clamd 3772 fhandler_base::set_flags: flags 0x10002, 
supplied_bin 0x0
 116 554739782 [main] clamd 3772 fhandler_base::set_flags: O_TEXT/O_BINARY 
set in flags 0x1
 111 554739893 [main] clamd 3772 fhandler_base::set_flags: filemode set to 
binary

 110 554740003 [main] clamd 3772 fdsock: fd 6, name '', soc 0x3FC
 109 554740112 [main] clamd 3772 fhandler_socket::accept: res 6
 522 554740634 [main] clamd 3772 cygwin_accept: 6 = accept (4, 0x0, 0x0)
153999229 708739863 [unknown (0x490)] clamd 3772 select_stuff::wait: timed 
out

 282 708740145 [unknown (0x490)] clamd 3772 select_stuff::wait: returning 1
 129 708740274 [unknown (0x490)] clamd 3772 select_stuff::cleanup: calling 
cleanup routines
 121 708740395 [unknown (0x490)] clamd 3772 socket_cleanup: si 0x10448370 
si->thread 0x610FFC08
 303 708740698 [unknown (0x490)] clamd 3772 socket_cleanup: sent a byte to 
exitsock 0x28C, res 1
1332 708742030 [select_socket] clamd 3772 thread_socket: Win32 select 
returned 1
 213 708742243 [select_socket] clamd 3772 thread_socket: s 0x10222FB0, 
testing fd 5 ()

 122 708742365 [select_socket] clamd 3772 thread_socket: saw exitsock read
 389 708742754 [unknown (0x490)] clamd 3772 socket_cleanup: reading a byte 
from exitsock 0x28C

 263 708743017 [unknown (0x490)] clamd 3772 socket_cleanup: recv returned 1
 250 708743267 [unknown (0x490)] clamd 3772 socket_cleanup: returning
 120 708743387 [unknown (0x490)] clamd 3772 peek_socket: considering handle 
0x7C
 116 708743503 [unknown (0x490)] clamd 3772 peek_socket: adding read fd_set 
, fd 5
 762 708744265 [unknown (0x490)] clamd 3772 peek_socket: adding except 
fd_set , fd 5
 429 708744694 [unknown (0x490)] clamd 3772 peek_socket: WINSOCK_SELECT 
returned 0

 155 708744849 [unknown (0x490)] clamd 3772 select_stuff::poll: returning 0
 118 708744967 [unknown (0x490)] clamd 377

Re: Serious performance problems (malloc related?)

[Igor Pechtchanski]

On Thu, 2 Jun 2005, Gerrit P. Haase wrote:

> Igor Pechtchanski wrote:
>
> > On Thu, 2 Jun 2005, Robb, Sam wrote:
> > > Is there any reason why the cygwin DLL couldn't be built
> > > twice: once for Win9x, and once for WinNT-based systems?
> > >
> > > Aside from potential installation issues ("install this
> > > version of the DLL under 9x, that version under NT), it
> > > seems like this would be a reasonable optimization.
>
> > As long as we're mulling over ideas...
>
> Alternatively, we could drop Win98 support.

Dropping it altogether would be unfortunate.  Providing Win98 support DLLs
in a separate package is a possibility.  There's still the point that CGF
raised, about there being many more people with the knowledge of Win32 API
than those with the knowledge of Nt* API.
Igor
-- 
http://cs.nyu.edu/~pechtcha/
  |\  _,,,---,,_[EMAIL PROTECTED]
ZZZzz /,`.-'`'-.  ;-;;,_[EMAIL PROTECTED]
 |,4-  ) )-,_. ,\ (  `'-'   Igor Pechtchanski, Ph.D.
'---''(_/--'  `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

"The Sun will pass between the Earth and the Moon tonight for a total
Lunar eclipse..." -- WCBS Radio Newsbrief, Oct 27 2004, 12:01 pm EDT

--
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/

Re: Serious performance problems (malloc related?)

[Keith Moore]

Igor Pechtchanski wrote:

> Dropping it altogether would be unfortunate.  Providing Win98 support DLLs
> in a separate package is a possibility.  There's still the point that CGF
> raised, about there being many more people with the knowledge of Win32 API
> than those with the knowledge of Nt* API.

Is there anything I can do to help with the Nt* conversion? I've been
using the native NT APIs for about 15 years. I'm not so familiar with
the APIs added in WinXP and 2003, but I'm *very* familiar with the core
API set.

I have recently received my official anoitment from Redhat so I can
officially contribute to Cygwin.


KM


--
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/

Re: Serious performance problems (malloc related?)

[Ralf Habacker]

Am Donnerstag, 2. Juni 2005 23:43 schrieb Keith Moore:
> Igor Pechtchanski wrote:
> 
> > Dropping it altogether would be unfortunate.  Providing Win98 support DLLs
> > in a separate package is a possibility.  There's still the point that CGF
> > raised, about there being many more people with the knowledge of Win32 API
> > than those with the knowledge of Nt* API.
> 
> Is there anything I can do to help with the Nt* conversion? I've been
> using the native NT APIs for about 15 years. I'm not so familiar with
> the APIs added in WinXP and 2003, but I'm *very* familiar with the core
> API set.

There were several attempts and many discussions in the past to speed up the 
fork implementation but unfortunally without any succes. Maybe using the NT 
api could help in this area. I found one thread indicating this as possible 
solution in  http://www.osronline.com/lists_archive/ntdev/thread4267.html

Ralf 

> I have recently received my official anoitment from Redhat so I can
> officially contribute to Cygwin.

 

--
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/

Re: Drop Win9x support? (was: Serious performance problems)

[Warren Young]

Gerrit P. Haase wrote:


Alternatively, we could drop Win98 support.


Yes!

The requirement made sense back when WinXP wasn't dominant yet.  By now, 
the last machines still running Win9x are dying or being replaced at a 
fairly high rate.  I'm glad Cygwin was available during the years it's 
taken for NT-based Windows to take over.  It was good work, but it's 
time to move on.


It's not like the current Cygwin totally sucks or anything.  I can 
continue using 1.5 on my last Win9x machine indefinitely.  The main 
reasons to update Cygwin are security fixes and new functionality, and 
neither is a serious concern on such legacy machines.


The tricky part is figuring out how to continue to make Cygwin 1.5 
available to those last souls who need Win9x support.


Perhaps this could coincide with whatever Cygwin 2.0 will be.  I imagine 
Cygwin 2.0 just being an opportunity to break the ABI, get rid of cruft, 
etc.  This would naturally solve the Cygwin 1.5 availability problem: 
the new stuff would appear in a different directory on the mirrors, 
perhaps containing "cygwin2" in the path name.  Then the current 
setup.exe will look in the current place for Cygwin, and get only 1.5. 
Those wanting the new stuff would get a new setup.exe, which will look 
in the cygwin2 location.


If there are still a few things people want to push into the last Cygwin 
1.5 releases, that's fine, too.  A little parallel development during a 
major version changeover never killed anyone.


Even if some of you disagree with whether to discontinue Win9x support 
now, some of these issues still bear discussing.  This day will come 
eventually.


--
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/

RE: Drop Win9x support? (was: Serious performance problems)

[Terry Dabbs]

No!

I am supporting applications requiring cygwin on '95 and '98 that are
not going away anytime soon.

Terry

Gerrit P. Haase wrote:
> 
> Alternatively, we could drop Win98 support.

Yes!

The requirement made sense back when WinXP wasn't dominant yet.  By now,
the last machines still running Win9x are dying or being replaced at a
fairly high rate.  I'm glad Cygwin was available during the years it's
taken for NT-based Windows to take over.  It was good work, but it's
time to move on.

It's not like the current Cygwin totally sucks or anything.  I can
continue using 1.5 on my last Win9x machine indefinitely.  The main
reasons to update Cygwin are security fixes and new functionality, and
neither is a serious concern on such legacy machines.

The tricky part is figuring out how to continue to make Cygwin 1.5
available to those last souls who need Win9x support.

Perhaps this could coincide with whatever Cygwin 2.0 will be.  I imagine
Cygwin 2.0 just being an opportunity to break the ABI, get rid of cruft,
etc.  This would naturally solve the Cygwin 1.5 availability problem: 
the new stuff would appear in a different directory on the mirrors,
perhaps containing "cygwin2" in the path name.  Then the current
setup.exe will look in the current place for Cygwin, and get only 1.5. 
Those wanting the new stuff would get a new setup.exe, which will look
in the cygwin2 location.

If there are still a few things people want to push into the last Cygwin
1.5 releases, that's fine, too.  A little parallel development during a
major version changeover never killed anyone.

Even if some of you disagree with whether to discontinue Win9x support
now, some of these issues still bear discussing.  This day will come
eventually.

--


--
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/

Re: Drop Win9x support? (was: Serious performance problems)

[Warren Young]

Terry Dabbs wrote:


I am supporting applications requiring cygwin on '95 and '98 that are
not going away anytime soon.


That's fine, but do you really need new functionality?

Again, I'm not saying "delete all Cygwin binaries that support Win9x". 
I'm saying "stop requiring Win9x compatibility in new binaries".


--
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/

Re: Drop Win9x support? (was: Serious performance problems)

[Gerrit P. Haase]

Terry Dabbs wrote:


No!

I am supporting applications requiring cygwin on '95 and '98 that are
not going away anytime soon.


I have not seen any Win98/ME PC since about 5 years, we're using NT all
over the place.  As I started to work in this business NT4 was current,
then W2K came up, now every new box is delivered with XP, all NT based
systems.  I cannot imagine why someone with a PC not older than 5 years
doesn't want to spend 100$ to buy an XP license.  It should always be
possible to run every Win98/ME binary on XP.  I was able to run some
old PC Games on XP which I couldn't run for about 5 years because the
lack of Win98 in my location.  The XP system supports running those old
binaries.  And if you really need Cygwin for Win98, you may use 1.5.x
forever.  As I have heard, there are still people out there who are
running NT4 Server, for about ten years now, using Cygwin B20 since
1999;)  It is fitting their needs, so why should they upgrade?


Gerrit
--
=^..^=

--
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/

Re: Drop Win9x support? (was: Serious performance problems)

[Igor Pechtchanski]

On Fri, 3 Jun 2005, Gerrit P. Haase wrote:

> Terry Dabbs wrote:
>
> > No!
> >
> > I am supporting applications requiring cygwin on '95 and '98 that are
> > not going away anytime soon.
>
> I have not seen any Win98/ME PC since about 5 years, we're using NT all
> over the place.  As I started to work in this business NT4 was current,
> then W2K came up, now every new box is delivered with XP, all NT based
> systems.  I cannot imagine why someone with a PC not older than 5 years
> doesn't want to spend 100$ to buy an XP license.  It should always be
> possible to run every Win98/ME binary on XP.  I was able to run some
> old PC Games on XP which I couldn't run for about 5 years because the
> lack of Win98 in my location.  The XP system supports running those old
> binaries.  And if you really need Cygwin for Win98, you may use 1.5.x
> forever.  As I have heard, there are still people out there who are
> running NT4 Server, for about ten years now, using Cygwin B20 since
> 1999;)  It is fitting their needs, so why should they upgrade?

Just a datapoint.  WinXP does *not* run all the programs that Win9x does.
There are ways around it, but some of the old DOS stuff interacts much
better with 9x, especially those that need to manipulate the video
framebuffer directly.  I'm not saying that Cygwin programs do that, but
this is one of the reasons to keep 9x around, and I, for one, do use
Cygwin on my old 9x machine.  And I would like to see the new features in
that Cygwin installation (the biggest problem, of course, isn't Cygwin
features per se, but packages -- the newly built ones require newer Cygwin
versions).

Again, IMO, it would be ok to make Win9x functionality slower, external to
the Cygwin DLL, etc, etc, but I don't think dropping it altogether is a
good idea.
Igor
-- 
http://cs.nyu.edu/~pechtcha/
  |\  _,,,---,,_[EMAIL PROTECTED]
ZZZzz /,`.-'`'-.  ;-;;,_[EMAIL PROTECTED]
 |,4-  ) )-,_. ,\ (  `'-'   Igor Pechtchanski, Ph.D.
'---''(_/--'  `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

"The Sun will pass between the Earth and the Moon tonight for a total
Lunar eclipse..." -- WCBS Radio Newsbrief, Oct 27 2004, 12:01 pm EDT

--
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/

RE: Compiling gcc4 on cygwin

[Billinghurst, David \(CALCRTS\)]

> From: Dr Ivan D. Reid 
> 
> Hello David;
>   I see you do regular reports on compiling gcc-4 on cygwin.
> 
>   Would it be possible for you to send me a copy of the 
> scripts you
> use?  I must be missing something as I get a failure when 
> make bootstrap-lean
> processes libiberty -- an excerpt below -- which suggests 
> that some include
> logic is going haywire.  Possibly I'm missing some tool or library?
> 
>   Thanks for any help,
>   ivan

Ivan,

I have a patch of Danny Smith's in my local tree for this
http://gcc.gnu.org/ml/gcc-patches/2005-05/msg9.html

There are later versions under discussion, including
http://gcc.gnu.org/ml/gcc-patches/2005-05/msg02945.html

I forgot to update my build script to mention the patch.
Just fixed that. Sorry for any confusion.


David


NOTICE
This e-mail and any attachments are private and confidential and may contain 
privileged information. If you are not an authorised recipient, the copying or 
distribution of this e-mail and any attachments is prohibited and you must not 
read, print or act in reliance on this e-mail or attachments.
This notice should not be removed.

--
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/

RE: Updated: cygwin-1.5.17-1

[Adye, TJ \(Tim\)]

Hi,

On 26 May 2005, Christopher Faylor wrote:

> I've made a new version of the Cygwin DLL and associated utilities
> available for download.  As usual, a list of what has changed 
> is below.
> [...]

> cgf: Make dlopen search /usr/bin (for Windows compatibility) 
> and /usr/lib (for UNIX compatibility).

The change seems to be a bit more drastic than that implies to me. I
believe that previously dlopen searched $PATH before, but it doesn't any
more.

I have a Cygwin program that loads a Windows DLL (afsauthent.dll) that
it used to find via the $PATH (found in C:\Program Files\OpenAFS\Common,
which OpenAFS adds to the Windows PATH, and is inherited by Cygwin).
That stopped working recently (Win32 error 126), probably when I updated
to cygwin-1.5.17-1 (I can check if this is in any doubt).

I can get it working again if I add /cygdrive/c/Program
Files/OpenAFS/Common to $LD_LIBRARY_PATH by hand.

Is this change deliberate? I would have thought that "Windows
compatibility" ought to include searching the PATH.

Regards,
Tim.

==  cut here  ==
Tim Adye, BaBar Group, Particle Physics Dept., _   /|
  Rutherford Appleton Laboratory, UK.  \'o.O'   Oop!
e-mail:   [EMAIL PROTECTED]=(___)=  Ack!
WWW:  http://hepwww.rl.ac.uk/Delphi/Adye/homepage.htmlU  Thphft!

--
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/

RE: Updated: cygwin-1.5.17-1

[Larry Hall]

At 07:33 PM 6/2/2005, you wrote:
>Hi,
>
>On 26 May 2005, Christopher Faylor wrote:
>
>> I've made a new version of the Cygwin DLL and associated utilities
>> available for download.  As usual, a list of what has changed 
>> is below.
>> [...]
>
>> cgf: Make dlopen search /usr/bin (for Windows compatibility) 
>> and /usr/lib (for UNIX compatibility).
>
>The change seems to be a bit more drastic than that implies to me. I
>believe that previously dlopen searched $PATH before, but it doesn't any
>more.
>
>I have a Cygwin program that loads a Windows DLL (afsauthent.dll) that
>it used to find via the $PATH (found in C:\Program Files\OpenAFS\Common,
>which OpenAFS adds to the Windows PATH, and is inherited by Cygwin).
>That stopped working recently (Win32 error 126), probably when I updated
>to cygwin-1.5.17-1 (I can check if this is in any doubt).


Yes, please do and report back.


--
Larry Hall  http://www.rfk.com
RFK Partners, Inc.  (508) 893-9779 - RFK Office
838 Washington Street   (508) 893-9889 - FAX
Holliston, MA 01746 


--
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/

Re: Serious performance problems (malloc related?)

[Linda W]

Might it be possible to build 2 versions and have the package
dynamically install the correct version?

On the other hand, instead of "if (win98)..." one could have a
cygwin1.dll that chooses a 2nd library to load and all entry points are
either runtime indirect calls into the 2nd library (cygwin_NT,
cygwin_nont).  The user could optimize by manually running a script that
copied the OS specific library in place of cygwin1.dll and setting a
flag in an /etc/sysconfig/libpref file so future updates of the library
could automatically install the OS-specific version when updating
the library.  To keep the option of what OS to use open, the "pointer-lib"
could be renamed to cygwin1_wrapper.dll when not used as the default.

BTW -- what % of users are still on win9x/me?  Is there any obsolescence
plan (not that I am pushing for such!)...

Just some ideas to mull around if a leaner memory footprint became
something of a priority...

linda


Christopher Faylor wrote:


OTOH, Corinna is hard at work adding low-level Nt* calls to cygwin so,
if it wasn't for the requirement that everything has to work on Windows
9x, the DLL would be smaller and faster.  Instead, every system call
currently needs to have a "do this if it's NT and that if it's 9x" test
so "we" have been slow in moving to bypass the win32 api layer on
Windows NT.

OTOH, we will rebuild it.  We do have the technology.

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/

 



--
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/

Re: performance problems

[Linda W]

I know, but truthfully, you are taking my response a bit out of context.

I was responding, specifically to CFG's message:


Christopher Faylor wrote:
> Yep.  This is pretty much what I expected.  Now we'll see a stream of
> people commenting on slowness and speculating on the cause without
> spending any time to actually figure out what the cause might be.
>
> Think of what a hero you'll be if you figure out a way to improve
> cygwin's "slowness".


Not everyone can do all things.  I didn't "speculate" on the cause, I
noticed multiple opens for a program that really only needs stat/lstat I 
believe.

Hero's can come up with ideas, but may not be the best people to
actually execute the plan or idea.  Some people are hero's because of a
reputation of excellent execution.  Some smaller number of people can do both.
I've found that while I can often come up with innovative ideas, I get
more bogged down in details when it comes to programming than _some_
consider beneficial.

It's been a while, but if I remember, I tried building it both
under cygwin(XP) & tried cross-compiling under linux (preferred, as my linux
box is 3-5x faster).  Perhaps using SuSE (9.1) as my distro causes problem
as cygwin was originally a Redhat effort?

I'm perfectly willing to try again, but I didn't want to bother
developers about questions they might consider "obvious", and I should go
read some obscure text (I did try to follow build instructions, but don't
remember if I ever ended up with anything useful).  I know the FAQ has
a rebuild under NT seection, is cygwin buildable on a linux system? :-)

Thanks for the helpful pointers...:-)

Linda



Igor Pechtchanski wrote:

.  .
Igor


--
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/

Re: Serious performance problems (malloc related?)

[Christopher Faylor]

On Thu, Jun 02, 2005 at 11:57:26PM +0200, Ralf Habacker wrote:
>Am Donnerstag, 2. Juni 2005 23:43 schrieb Keith Moore:
>> Igor Pechtchanski wrote:
>>>Dropping it altogether would be unfortunate.  Providing Win98 support
>>>DLLs in a separate package is a possibility.  There's still the point
>>>that CGF raised, about there being many more people with the knowledge
>>>of Win32 API than those with the knowledge of Nt* API.
>>
>>Is there anything I can do to help with the Nt* conversion?  I've been
>>using the native NT APIs for about 15 years.  I'm not so familiar with
>>the APIs added in WinXP and 2003, but I'm *very* familiar with the core
>>API set.
>
>There were several attempts and many discussions in the past to speed
>up the fork implementation but unfortunally without any succes.

I did speed up fork slightly many years ago.  After that all that I
remember is that there was a time where every few months someone would
say "Hey! We can use copy on write! Why didn't anyone ever think of that
before?" Then they'd find some past message of mine where I said that
I'd tried it and it really didn't help much.  Then sometimes I would get
personal email asking for in-depth brain dump of everything I did.

I tried this with both Nt routines and with the shared memory copy on
write without much luck.

And, no, I don't have the code anymore and I don't remember what I did
but I'm pretty sure I didn't do something so egregiously wrong that I
would have missed a noticeable speed improvement.

Cygwin uses {Read,Write}ProcessMemory to copy memory and AFAICT, 
these are actually pretty fast functions.  There are a lot of things
that fork has to do besides just duplicate memory from the parent to the
child.  I'm not sure how Nt routines would help out there.

That is not to say that there isn't some place that could be improved
but, as always, I doubt that anyone is going to find a way to improve
things by speculating without actually inspecting the source code.

Keith, you don't have a complete reference for the Nt functions do you?


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/

dlopen does not search the path

[Christopher Faylor]

On Fri, Jun 03, 2005 at 12:33:55AM +0100, Adye, TJ (Tim) wrote:
>Hi,
>
>On 26 May 2005, Christopher Faylor wrote:
>
>> I've made a new version of the Cygwin DLL and associated utilities
>> available for download.  As usual, a list of what has changed 
>> is below.
>> [...]
>
>> cgf: Make dlopen search /usr/bin (for Windows compatibility) 
>> and /usr/lib (for UNIX compatibility).
>
>The change seems to be a bit more drastic than that implies to me. I
>believe that previously dlopen searched $PATH before, but it doesn't any
>more.
>
>I have a Cygwin program that loads a Windows DLL (afsauthent.dll) that
>it used to find via the $PATH (found in C:\Program Files\OpenAFS\Common,
>which OpenAFS adds to the Windows PATH, and is inherited by Cygwin).
>That stopped working recently (Win32 error 126), probably when I updated
>to cygwin-1.5.17-1 (I can check if this is in any doubt).
>
>I can get it working again if I add /cygdrive/c/Program
>Files/OpenAFS/Common to $LD_LIBRARY_PATH by hand.
>
>Is this change deliberate? I would have thought that "Windows
>compatibility" ought to include searching the PATH.

It was not deliberate and, in fact, the change in behavior had nothing
to do with the change to make dlopen search /usr/bin and /usr/lib.  It
was, however, another change of mine so I still have to take the blame.

I've checked in a fix.  It will be in the next snapshot.

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/

Re: performance problems

[Brian Dessent]

Linda W wrote:

> Not everyone can do all things.  I didn't "speculate" on the cause, I
> noticed multiple opens for a program that really only needs stat/lstat I 
> believe.

In order to implement stat(), cygwin has to call NtQueryInformationFile
(GetFileInformationByHandle for 9x/me) and this requires the file to be
opened.  Thus the reason that stat takes forever is that each file has
to be opened, and this is expensive.  I think Cygwin can take several
shortcuts if it knows that not all the stat information is needed (for
example, if it doesn't care if the file is executable or if it has been
told that all files in the directory are to be treated as executable)
but in most cases the file still has to be opened.

> It's been a while, but if I remember, I tried building it both
> under cygwin(XP) & tried cross-compiling under linux (preferred, as my linux
> box is 3-5x faster).  Perhaps using SuSE (9.1) as my distro causes problem
> as cygwin was originally a Redhat effort?

Why would the distro matter?  All you really need is a working cross
compiler, and the regular build tools (autoconf, automake, perl, awk,
make.)  It's all standard stuff and nothing is redhat-specific.  I build
under a Debian linux system often and it works fine.  The guide to
building a cross compiler in the X users guide is a good source of
instructions.  Note that if you don't also have a mingw cross compiler
you won't be able to build from the toplevel build directory, because
this by default builds all the w32api import libs etc. and this calls
gcc with -mno-cygwin.  You can easily sidestep this requirement by
building in i686-pc-cygwin/winsup/cygwin (or ../utils) instead of the
toplevel build dir.

> remember if I ever ended up with anything useful).  I know the FAQ has
> a rebuild under NT seection, is cygwin buildable on a linux system? :-)

I think you will find that the cygwin DLL (and most of the base system)
you are using now was probably cross-compiled.

Brian

--
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/

Re: Drop Win9x support? (was: Serious performance problems)

[Gerrit P. Haase]

Igor Pechtchanski wrote:


On Fri, 3 Jun 2005, Gerrit P. Haase wrote:



Terry Dabbs wrote:



No!

I am supporting applications requiring cygwin on '95 and '98 that are
not going away anytime soon.


I have not seen any Win98/ME PC since about 5 years, we're using NT all
over the place.  As I started to work in this business NT4 was current,
then W2K came up, now every new box is delivered with XP, all NT based
systems.  I cannot imagine why someone with a PC not older than 5 years
doesn't want to spend 100$ to buy an XP license.  It should always be
possible to run every Win98/ME binary on XP.  I was able to run some
old PC Games on XP which I couldn't run for about 5 years because the
lack of Win98 in my location.  The XP system supports running those old
binaries.  And if you really need Cygwin for Win98, you may use 1.5.x
forever.  As I have heard, there are still people out there who are
running NT4 Server, for about ten years now, using Cygwin B20 since
1999;)  It is fitting their needs, so why should they upgrade?



Just a datapoint.  WinXP does *not* run all the programs that Win9x does.
There are ways around it, but some of the old DOS stuff interacts much
better with 9x, especially those that need to manipulate the video
framebuffer directly.  I'm not saying that Cygwin programs do that, but
this is one of the reasons to keep 9x around, and I, for one, do use
Cygwin on my old 9x machine.  And I would like to see the new features in
that Cygwin installation (the biggest problem, of course, isn't Cygwin
features per se, but packages -- the newly built ones require newer Cygwin
versions).


DOS is not Win98, what is DOS BTW?



Again, IMO, it would be ok to make Win9x functionality slower, external to
the Cygwin DLL, etc, etc, but I don't think dropping it altogether is a
good idea.


Gerrit
--
=^..^=

--
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/

Re: performance problems

[Christopher Faylor]

On Thu, Jun 02, 2005 at 06:32:00PM -0700, Brian Dessent wrote:
>I think you will find that the cygwin DLL (and most of the base system)
>you are using now was probably cross-compiled.

Yup.  And, these days, it's cross-compiled on a Debian-based system.

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/

RE: Compiling gcc4 on cygwin

[Dr Ivan D. Reid]

On Fri, 3 Jun 2005, Billinghurst, David (CALCRTS) wrote:

> > From: Dr Ivan D. Reid 
> > 
> > Hello David;
> > I see you do regular reports on compiling gcc-4 on cygwin.
> > 
> > Would it be possible for you to send me a copy of the 
> > scripts you
> > use?  I must be missing something as I get a failure when 
> > make bootstrap-lean
> > processes libiberty -- an excerpt below -- which suggests 
> > that some include
> > logic is going haywire.  Possibly I'm missing some tool or library?
> > 
> > Thanks for any help,
> > ivan
> 
> Ivan,
> 
> I have a patch of Danny Smith's in my local tree for this
> http://gcc.gnu.org/ml/gcc-patches/2005-05/msg9.html
> 
> There are later versions under discussion, including
> http://gcc.gnu.org/ml/gcc-patches/2005-05/msg02945.html
> 
> I forgot to update my build script to mention the patch.
> Just fixed that. Sorry for any confusion.
> 
Thanks, I'll take a look at that in the morning.

ivsn

-- 
Ivan Reid, Electronic & Computer Engineering, ___ CMS  Collaboration,
Brunel University. [EMAIL PROTECTED] Room 40-1-B12, CERN


--
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/

Re: performance problems

[Larry Hall]

At 09:40 PM 6/2/2005, Christopher Faylor wrote:
>On Thu, Jun 02, 2005 at 06:32:00PM -0700, Brian Dessent wrote:
>>I think you will find that the cygwin DLL (and most of the base system)
>>you are using now was probably cross-compiled.
>
>Yup.  And, these days, it's cross-compiled on a Debian-based system.


Huh?  Bite your tongue! ;-)


--
Larry Hall  http://www.rfk.com
RFK Partners, Inc.  (508) 893-9779 - RFK Office
838 Washington Street   (508) 893-9889 - FAX
Holliston, MA 01746 


--
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/

Re: performance problems

[Christopher Faylor]

On Thu, Jun 02, 2005 at 11:21:16PM -0400, Larry Hall wrote:
>At 09:40 PM 6/2/2005, Christopher Faylor wrote:
>>On Thu, Jun 02, 2005 at 06:32:00PM -0700, Brian Dessent wrote:
>>>I think you will find that the cygwin DLL (and most of the base system)
>>>you are using now was probably cross-compiled.
>>
>>Yup.  And, these days, it's cross-compiled on a Debian-based system.
>
>Huh?  Bite your tongue! ;-)

Well, I run distcc so actually it is built on Debian, Fedora, gentoo
AMD64, and gentoo x86.  I guess I should get a SuSE system someday.

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/

RE: Compiling gcc4 on cygwin

[Dr Ivan D. Reid]

On Fri, 3 Jun 2005, Dr Ivan D. Reid wrote:

> On Fri, 3 Jun 2005, Billinghurst, David (CALCRTS) wrote:
> > 
> > Ivan,
> > 
> > I have a patch of Danny Smith's in my local tree for this
> > http://gcc.gnu.org/ml/gcc-patches/2005-05/msg9.html
> > 
> > There are later versions under discussion, including
> > http://gcc.gnu.org/ml/gcc-patches/2005-05/msg02945.html
> > 
> > I forgot to update my build script to mention the patch.
> > Just fixed that. Sorry for any confusion.
 
>   Thanks, I'll take a look at that in the morning.

Now there's magic!  Thanks mate, that seems to have worked.

ivan

-- 
Ivan Reid, Electronic & Computer Engineering, ___ CMS  Collaboration,
Brunel University. [EMAIL PROTECTED] Room 40-1-B12, CERN


--
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/