Mail Archives: cygwin/2001/04/29/07:31:58
Hello,
If your response is the "official" response, I feel
sorry for the Cygwin project as the performance problem
is not my specific problem but a problem in general.
The test results that I sent were for the execution
of ./configure, which does not run one line of my
code (though the precise sequence of calls is determined
by my configure.in).
Thanks for your advice about pthread_cancel(). I'll
stop using Cygwin pthreads, which will allow me to go back to
Cygwin 1.1.5 eliminating the performance penalty.
Regards,
Kern
-----Original Message-----
From: Robert Collins [SMTP:robert DOT collins AT itdomain DOT com DOT au]
Sent: Sunday, 29 April 2001 10:35 AM
To: kern AT sibbald DOT com
Cc: cygwin AT cygwin DOT com
Subject: RE: Some comments about the current release
> -----Original Message-----
> From: Kern Sibbald [mailto:kern AT sibbald DOT com]
> Sent: Sunday, April 29, 2001 6:23 PM
> To: Robert Collins
> Cc: 'cygwin AT cygwin DOT com'
> Subject: RE: Some comments about the current release
>
>
> Hello Robert,
>
> Thanks for the comments.
>
> - Oops. I should have asked you to provide a null
> libpthread.a library (no s).
>
> - Perhaps my makefiles were broken in assuming
> libpthread.a is the library name, but it DOES
> seem to be commonly used for POSIX threads.
> Why not make life easier for people like
> me with "broken" makefiles? Of course, using
> autoconf, I corrected the problem so it is
> no longer a problem for me.
sidenote) this translates as "backward compatability".
a) Search the cygwin mailing list for -lm or libm. See how many crashes,
stackdumps and general other unpleasantness have occured. This problem
is now fixed, but I have _no_ intention of creating another.
b) Because I can't be bothered. There I said it. I'm lazy. I'd rather
code a little more backend support into cygwin than deal with altering
setup.exe to create another symlink to fix makefiles in broken projects
that are already unportable. I'd rather encourage developers to write
portable code and portable makefiles. If cygwin was creating a *new* way
of doing it, backwards compatability would be a good answer. As we're
not... it isn't.
> - I appreciate the improved pthreads support. It seems
> to function well for the functions I am using.
> I tried using pthreads in 1.1.5 and saw that it
> was there, but it lacked pthread_cancel(), which
> is why I upgraded to 1.3.1.
pthread_cancel is not operational just yet :]. Don't depend on it. (See
thread.cc for comments).
> - My problem with winsock2.h is that I have part
> of the program that is strictly Microsoft (the
> part that makes apcupsd a service, handles the tray
> icon, and the dialog boxes for the tray) and
> a part that is Unix, which is the vast majority
> of the program. I know the problem isn't simple
> but I just wanted to mention it.
Well you mislead us. You stated
===
> 4. I was including <winsock2.h> in a bunch of header files
> in my .cpp programs which are strictly Windows (no Unix
> stuff) and I got lots of warning messages, which were
===
which quite clearly indicates that you had "no Unix stuff". You cannot
expect sensible answers when you provide half the question.
> I hope someone can find a solution for the performance
> problems with version 1.3.1 cygwin1.dll that I mentioned.
We/they might. Of course _you_ are able to get a debug version of
cygwin1.dll and profile it. You might even see what's affecting you
specifically.
Rob
> Best regards,
>
> Kern
--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple
- Raw text -