Re: [PATCH] inform user if any postinstall script failed to run
On 28/08/2010 17:40, Christopher Faylor wrote: On Sat, Aug 28, 2010 at 01:30:54PM +0100, Jon TURNEY wrote: On 27/08/2010 19:33, Christopher Faylor wrote: On Fri, Aug 27, 2010 at 06:15:38PM +0100, Jon TURNEY wrote: On 29/07/2010 17:28, Jon TURNEY wrote: On 28/07/2010 15:58, Christopher Faylor wrote: On Wed, Jul 28, 2010 at 03:25:17PM +0100, Jon TURNEY wrote: Anyhow, here's another attempt, which unfortunately changes rather more than I wanted to. It adds a new page, which is displayed if any script failed, and reports which packages and scripts failed. That is great. Please check in (with a ChangeLog of course). Due to the way I tested this change, I'd failed to notice that when a package is installed with a failing postinstall script, this will list the failing script twice, once with the package name and once as 'no package'. Attached is a patch to remedy that. Do we realy need a separate for loop for this? Couldn't we just piggy back on the previous for loop? Sure. I'm not sure if it's any more elegant, though :-) Yow. No, it isn't. I didn't think you'd need to modify RunScript to deal with the behavior. So, nevermind. The previous solution looks simpler. Please go ahead with that one. Okay, done
/dev/windows and select() [was Re: Slow response to keypresses in xorg-server-1.8.0-1]
On 08/08/2010 12:04, Andy Koppe wrote:
On 7 August 2010 23:07, Jon TURNEY wrote:
Hmmm, looking again at the implementation of select(), I don't immediately
see that when waiting on /dev/windows, it checks that the message queue has
old messages on it before waiting. The MSDN documentation for
MsgWaitForMultipleObjects() seems to says that messages which had arrived
before the last PeekMessage() etc. aren't considered new and so don't end
the wait?
I think you're right, a call to PeekMessage is needed for proper
select() semantics: it shouldn't block if data is available for
reading.
Attached is a small test-case which seems to demonstrate this problem.
Run ./dev-windows-select-test and observe select() blocks for the full
timeout, despite the fact that the /dev/windows fd is ready for reading (and
it reported as such as the end of the timeout)
If you run './dev-windows-select-test -skip' to skip the PeekMessage(),
select() returns immediately, indicating the /dev/windows fd is ready for reading.
#include stdio.h
#include fcntl.h
#include sys/select.h
#include errno.h
#include windows.h
// gcc -o dev-windows-select-test.exe dev-windows-select-test.c -Wall -mwindows
int main(int argc, char *argv[])
{
int fd = open(/dev/windows, O_RDONLY);
if (PostMessage(NULL, WM_USER, 0, 0) != 0)
printf(PostMessage succeeded\n);
else
printf(PostMessage failed\n);
if (argc = 1)
{
MSG msg;
if (PeekMessage(msg, NULL, 0, 0, PM_NOREMOVE))
printf(PeekMessage reports a message available\n);
}
struct timeval timeout;
timeout.tv_sec = 5;
timeout.tv_usec = 0;
fd_set readfds;
FD_ZERO(readfds);
FD_SET(fd, readfds);
int rc = select(fd+1, readfds, NULL, NULL, timeout);
printf(select returned %d %s\n, rc, strerror(errno));
return 0;
}
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://x.cygwin.com/docs/
FAQ: http://x.cygwin.com/docs/faq/
Re: /dev/windows and select() [was Re: Slow response to keypresses in xorg-server-1.8.0-1]
On Aug 29 14:39, Jon TURNEY wrote:
On 08/08/2010 12:04, Andy Koppe wrote:
On 7 August 2010 23:07, Jon TURNEY wrote:
Hmmm, looking again at the implementation of select(), I don't immediately
see that when waiting on /dev/windows, it checks that the message queue has
old messages on it before waiting. The MSDN documentation for
MsgWaitForMultipleObjects() seems to says that messages which had arrived
before the last PeekMessage() etc. aren't considered new and so don't end
the wait?
I think you're right, a call to PeekMessage is needed for proper
select() semantics: it shouldn't block if data is available for
reading.
Attached is a small test-case which seems to demonstrate this problem.
Run ./dev-windows-select-test and observe select() blocks for the
full timeout, despite the fact that the /dev/windows fd is ready for
reading (and it reported as such as the end of the timeout)
If you run './dev-windows-select-test -skip' to skip the
PeekMessage(), select() returns immediately, indicating the
/dev/windows fd is ready for reading.
[...]
Thanks for the testcase. I examined this and I think I have a
workaround. MSDN states that there's a flag QS_ALLPOSTMESSAGE for
MsgWaitForMultipleObjects, which is not cleared by PeekMessage, if the
wMsgFilterMin and wMsgFilterMax arguments are not both 0. So, what I
did was to add the QS_ALLPOSTMESSAGE flag to the
MsgWaitForMultipleObjects call in select.cc, and to change the
PeekMessage call in select.cc:peek_windows() from
PeekMessage (m, (HWND) h, 0, 0, PM_NOREMOVE)
to
PeekMessage (m, (HWND) h, 1, UINT_MAX, PM_NOREMOVE)
Same in your above test application. This appears to do the trick.
However, I'm not exactly sure if that's a valid fix. Patch below.
Corinna
Index: select.cc
===
RCS file: /cvs/src/src/winsup/cygwin/select.cc,v
retrieving revision 1.160
diff -u -p -r1.160 select.cc
--- select.cc 2 Apr 2010 22:36:44 - 1.160
+++ select.cc 29 Aug 2010 14:16:18 -
@@ -287,7 +287,8 @@ select_stuff::wait (fd_set *readfds, fd_
if (!windows_used)
wait_ret = WaitForMultipleObjects (m, w4, FALSE, ms);
else
- wait_ret = MsgWaitForMultipleObjects (m, w4, FALSE, ms, QS_ALLINPUT);
+ wait_ret = MsgWaitForMultipleObjects (m, w4, FALSE, ms,
+ QS_ALLINPUT | QS_ALLPOSTMESSAGE);
switch (wait_ret)
{
@@ -1531,7 +1532,7 @@ peek_windows (select_record *me, bool)
if (me-read_selected me-read_ready)
return 1;
- if (PeekMessage (m, (HWND) h, 0, 0, PM_NOREMOVE))
+ if (PeekMessage (m, (HWND) h, 1, UINT_MAX, PM_NOREMOVE))
{
me-read_ready = true;
select_printf (window %d(%p) ready, me-fd, me-fh-get_handle ());
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://x.cygwin.com/docs/
FAQ: http://x.cygwin.com/docs/faq/
Re: /dev/windows and select() [was Re: Slow response to keypresses in xorg-server-1.8.0-1]
On Aug 29 16:17, Corinna Vinschen wrote: On Aug 29 14:39, Jon TURNEY wrote: On 08/08/2010 12:04, Andy Koppe wrote: On 7 August 2010 23:07, Jon TURNEY wrote: Hmmm, looking again at the implementation of select(), I don't immediately see that when waiting on /dev/windows, it checks that the message queue has old messages on it before waiting. The MSDN documentation for MsgWaitForMultipleObjects() seems to says that messages which had arrived before the last PeekMessage() etc. aren't considered new and so don't end the wait? [...] Thanks for the testcase. I examined this and I think I have a workaround. MSDN states that there's a flag QS_ALLPOSTMESSAGE for MsgWaitForMultipleObjects, which is not cleared by PeekMessage, if the wMsgFilterMin and wMsgFilterMax arguments are not both 0. So, what I did was to add the QS_ALLPOSTMESSAGE flag to the MsgWaitForMultipleObjects call in select.cc, and to change the PeekMessage call in select.cc:peek_windows() from PeekMessage (m, (HWND) h, 0, 0, PM_NOREMOVE) to PeekMessage (m, (HWND) h, 1, UINT_MAX, PM_NOREMOVE) Same in your above test application. This appears to do the trick. However, I'm not exactly sure if that's a valid fix. Patch below. Hmm, this ignores the potential WM_NULL message, afaics. For some reason, using PeekMessage (m, (HWND) h, 0, UINT_MAX, PM_NOREMOVE) results in MsgWaitForMultipleObjects hanging, too. OTOH, using PeekMessage (m, (HWND) h, 0, 16, PM_NOREMOVE) PeekMessage (m, (HWND) h, 17, UINT_MAX, PM_NOREMOVE) does not. Go figure. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: /dev/windows and select() [was Re: Slow response to keypresses in xorg-server-1.8.0-1]
On Aug 29 16:41, Corinna Vinschen wrote: On Aug 29 16:17, Corinna Vinschen wrote: On Aug 29 14:39, Jon TURNEY wrote: On 08/08/2010 12:04, Andy Koppe wrote: On 7 August 2010 23:07, Jon TURNEY wrote: Hmmm, looking again at the implementation of select(), I don't immediately see that when waiting on /dev/windows, it checks that the message queue has old messages on it before waiting. The MSDN documentation for MsgWaitForMultipleObjects() seems to says that messages which had arrived before the last PeekMessage() etc. aren't considered new and so don't end the wait? [...] Thanks for the testcase. I examined this and I think I have a workaround. MSDN states that there's a flag QS_ALLPOSTMESSAGE for MsgWaitForMultipleObjects, which is not cleared by PeekMessage, if the wMsgFilterMin and wMsgFilterMax arguments are not both 0. So, what I did was to add the QS_ALLPOSTMESSAGE flag to the MsgWaitForMultipleObjects call in select.cc, and to change the PeekMessage call in select.cc:peek_windows() from PeekMessage (m, (HWND) h, 0, 0, PM_NOREMOVE) to PeekMessage (m, (HWND) h, 1, UINT_MAX, PM_NOREMOVE) Same in your above test application. This appears to do the trick. However, I'm not exactly sure if that's a valid fix. Patch below. Hmm, this ignores the potential WM_NULL message, afaics. For some reason, using PeekMessage (m, (HWND) h, 0, UINT_MAX, PM_NOREMOVE) results in MsgWaitForMultipleObjects hanging, too. OTOH, using PeekMessage (m, (HWND) h, 0, 16, PM_NOREMOVE) PeekMessage (m, (HWND) h, 17, UINT_MAX, PM_NOREMOVE) does not. Go figure. Yeah, I realize I'm talking to myself, but this works, too: PeekMessage (m, (HWND) h, 0, UINT_MAX - 1, PM_NOREMOVE) Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: /dev/windows and select() [was Re: Slow response to keypresses in xorg-server-1.8.0-1]
We are listening and learning :-) Dave Sent from my iPad On Aug 29, 2010, at 9:51 AM, Corinna Vinschen corinna-cyg...@cygwin.com wrote: On Aug 29 16:41, Corinna Vinschen wrote: On Aug 29 16:17, Corinna Vinschen wrote: On Aug 29 14:39, Jon TURNEY wrote: On 08/08/2010 12:04, Andy Koppe wrote: On 7 August 2010 23:07, Jon TURNEY wrote: Hmmm, looking again at the implementation of select(), I don't immediately see that when waiting on /dev/windows, it checks that the message queue has old messages on it before waiting. The MSDN documentation for MsgWaitForMultipleObjects() seems to says that messages which had arrived before the last PeekMessage() etc. aren't considered new and so don't end the wait? [...] Thanks for the testcase. I examined this and I think I have a workaround. MSDN states that there's a flag QS_ALLPOSTMESSAGE for MsgWaitForMultipleObjects, which is not cleared by PeekMessage, if the wMsgFilterMin and wMsgFilterMax arguments are not both 0. So, what I did was to add the QS_ALLPOSTMESSAGE flag to the MsgWaitForMultipleObjects call in select.cc, and to change the PeekMessage call in select.cc:peek_windows() from PeekMessage (m, (HWND) h, 0, 0, PM_NOREMOVE) to PeekMessage (m, (HWND) h, 1, UINT_MAX, PM_NOREMOVE) Same in your above test application. This appears to do the trick. However, I'm not exactly sure if that's a valid fix. Patch below. Hmm, this ignores the potential WM_NULL message, afaics. For some reason, using PeekMessage (m, (HWND) h, 0, UINT_MAX, PM_NOREMOVE) results in MsgWaitForMultipleObjects hanging, too. OTOH, using PeekMessage (m, (HWND) h, 0, 16, PM_NOREMOVE) PeekMessage (m, (HWND) h, 17, UINT_MAX, PM_NOREMOVE) does not. Go figure. Yeah, I realize I'm talking to myself, but this works, too: PeekMessage (m, (HWND) h, 0, UINT_MAX - 1, PM_NOREMOVE) Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
winsup/cygwin ChangeLog automode.c binmode.c c ...
CVSROOT:/cvs/uberbaum Module name:winsup Changes by: c...@sourceware.org 2010-08-30 01:57:37 Modified files: cygwin : ChangeLog automode.c binmode.c crt0.c globals.cc gmon.c profil.c textmode.c textreadmode.c winsup.h cygwin/include/sys: cygwin.h cygwin/lib : cygwin_attach_dll.c dll_main.cc Log message: * winlean.h: New file. * automode.c: Use winlean.h. * binmode.c: Ditto. * gmon.c: Ditto. * textmode.c: Ditto. * textreadmode.c: Ditto. * winsup.h: Ditto. * lib/cygwin_attach_dll.c: Ditto. * lib/dll_main.cc: Ditto. * profile.c: Ditto. * crt0.c: Ditto. Cleanup ancient cruft. Add dummy calls to cygwin_premain*. * include/sys/cygwin.h: Remove old stuff. Move premain declarations nearer to other cygwin-specific function declarations. * globals.cc: Add comment. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/winsup/cygwin/ChangeLog.diff?cvsroot=uberbaumr1=1.5013r2=1.5014 http://sourceware.org/cgi-bin/cvsweb.cgi/winsup/cygwin/automode.c.diff?cvsroot=uberbaumr1=1.4r2=1.5 http://sourceware.org/cgi-bin/cvsweb.cgi/winsup/cygwin/binmode.c.diff?cvsroot=uberbaumr1=1.5r2=1.6 http://sourceware.org/cgi-bin/cvsweb.cgi/winsup/cygwin/crt0.c.diff?cvsroot=uberbaumr1=1.4r2=1.5 http://sourceware.org/cgi-bin/cvsweb.cgi/winsup/cygwin/globals.cc.diff?cvsroot=uberbaumr1=1.20r2=1.21 http://sourceware.org/cgi-bin/cvsweb.cgi/winsup/cygwin/gmon.c.diff?cvsroot=uberbaumr1=1.6r2=1.7 http://sourceware.org/cgi-bin/cvsweb.cgi/winsup/cygwin/profil.c.diff?cvsroot=uberbaumr1=1.7r2=1.8 http://sourceware.org/cgi-bin/cvsweb.cgi/winsup/cygwin/textmode.c.diff?cvsroot=uberbaumr1=1.5r2=1.6 http://sourceware.org/cgi-bin/cvsweb.cgi/winsup/cygwin/textreadmode.c.diff?cvsroot=uberbaumr1=1.1r2=1.2 http://sourceware.org/cgi-bin/cvsweb.cgi/winsup/cygwin/winsup.h.diff?cvsroot=uberbaumr1=1.231r2=1.232 http://sourceware.org/cgi-bin/cvsweb.cgi/winsup/cygwin/include/sys/cygwin.h.diff?cvsroot=uberbaumr1=1.90r2=1.91 http://sourceware.org/cgi-bin/cvsweb.cgi/winsup/cygwin/lib/cygwin_attach_dll.c.diff?cvsroot=uberbaumr1=1.6r2=1.7 http://sourceware.org/cgi-bin/cvsweb.cgi/winsup/cygwin/lib/dll_main.cc.diff?cvsroot=uberbaumr1=1.4r2=1.5
winsup/cygwin winlean.h
CVSROOT:/cvs/uberbaum Module name:winsup Changes by: c...@sourceware.org 2010-08-30 02:09:30 Added files: cygwin : winlean.h Log message: add missing file Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/winsup/cygwin/winlean.h.diff?cvsroot=uberbaumr1=NONEr2=1.1
[ANNOUNCEMENT] New: rakudo-star-201007-1, Updated: rakudo-201007_47-1 (aka perl6)
rakudo-star on cygwin is parrot plus rakudo (a perl6 implemention on parrot) plus some new perl6 libraries, docs and libraries and blizkost, a perl5 parrot language which embeds libperl5. Contrary to the upstream rakudo-star release for the masses, this does not include the external parrot or rakudo releases. The external rakudo releases in the future will match the rakudo star release. That's why this rakudo has the version 201007_47, not just 201007, because it's the one from rakudo-star * first package, using external parrot, and an updated rakudo 2010.07-47 * some blizkost and make install patches (already applied upstream) * some testing hacks UPSTREAM ANNOUNCE On behalf of the Rakudo and Perl 6 development teams, I'm happy to announce the July 2010 release of Rakudo Star, a useful and usable distribution of Perl 6. The tarball for the July 2010 release is available from http://github.com/rakudo/star/downloads. Rakudo Star is aimed at early adopters of Perl 6. We know that it still has some bugs, it is far slower than it ought to be, and there are some advanced pieces of the Perl 6 language specification that aren't implemented yet. But Rakudo Perl 6 in its current form is also proving to be viable (and fun) for developing applications and exploring a great new language. These Star releases are intended to make Perl 6 more widely available to programmers, grow the Perl 6 codebase, and gain additional end-user feedback about the Perl 6 language and Rakudo's implementation of it. In the Perl 6 world, we make a distinction between the language (Perl 6) and specific implementations of the language such as Rakudo Perl. Rakudo Star is a distribution that includes release #31 of the Rakudo Perl 6 compiler [1], version 2.6.0 of the Parrot Virtual Machine [2], and various modules, documentation, and other resources collected from the Perl 6 community. We plan to make Rakudo Star releases on a monthly schedule, with occasional special releases in response to important bugfixes or changes. -- Reini Urban = To update your installation, click on the Install Cygwin now link on the http://cygwin.com/ web page. This downloads setup.exe to your system. Once you've downloaded setup.exe, run it and select Editors or Text and then click on the appropriate fields until the above announced version numbers appear if they are not displayed already. If your mirror doesn't yet have the latest version of this package after 24 hours, you can either continue to wait for that site to be updated or you can try to find another mirror. Please send questions or comments to the Cygwin mailing list at: cygwin@cygwin.com If you want to subscribe go to: http://cygwin.com/ml/cygwin/ I would appreciate if you would use this mailing list rather than emailing me directly. This includes ideas and comments about the setup utility or Cygwin in general. If you want to make a point or ask a question the Cygwin mailing list is the appropriate place. -- 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/ -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
/dev/windows and select() [was Re: Slow response to keypresses in xorg-server-1.8.0-1]
On 08/08/2010 12:04, Andy Koppe wrote:
On 7 August 2010 23:07, Jon TURNEY wrote:
Hmmm, looking again at the implementation of select(), I don't immediately
see that when waiting on /dev/windows, it checks that the message queue has
old messages on it before waiting. The MSDN documentation for
MsgWaitForMultipleObjects() seems to says that messages which had arrived
before the last PeekMessage() etc. aren't considered new and so don't end
the wait?
I think you're right, a call to PeekMessage is needed for proper
select() semantics: it shouldn't block if data is available for
reading.
Attached is a small test-case which seems to demonstrate this problem.
Run ./dev-windows-select-test and observe select() blocks for the full
timeout, despite the fact that the /dev/windows fd is ready for reading (and
it reported as such as the end of the timeout)
If you run './dev-windows-select-test -skip' to skip the PeekMessage(),
select() returns immediately, indicating the /dev/windows fd is ready for reading.
#include stdio.h
#include fcntl.h
#include sys/select.h
#include errno.h
#include windows.h
// gcc -o dev-windows-select-test.exe dev-windows-select-test.c -Wall -mwindows
int main(int argc, char *argv[])
{
int fd = open(/dev/windows, O_RDONLY);
if (PostMessage(NULL, WM_USER, 0, 0) != 0)
printf(PostMessage succeeded\n);
else
printf(PostMessage failed\n);
if (argc = 1)
{
MSG msg;
if (PeekMessage(msg, NULL, 0, 0, PM_NOREMOVE))
printf(PeekMessage reports a message available\n);
}
struct timeval timeout;
timeout.tv_sec = 5;
timeout.tv_usec = 0;
fd_set readfds;
FD_ZERO(readfds);
FD_SET(fd, readfds);
int rc = select(fd+1, readfds, NULL, NULL, timeout);
printf(select returned %d %s\n, rc, strerror(errno));
return 0;
}
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: /dev/windows and select() [was Re: Slow response to keypresses in xorg-server-1.8.0-1]
On Aug 29 14:39, Jon TURNEY wrote:
On 08/08/2010 12:04, Andy Koppe wrote:
On 7 August 2010 23:07, Jon TURNEY wrote:
Hmmm, looking again at the implementation of select(), I don't immediately
see that when waiting on /dev/windows, it checks that the message queue has
old messages on it before waiting. The MSDN documentation for
MsgWaitForMultipleObjects() seems to says that messages which had arrived
before the last PeekMessage() etc. aren't considered new and so don't end
the wait?
I think you're right, a call to PeekMessage is needed for proper
select() semantics: it shouldn't block if data is available for
reading.
Attached is a small test-case which seems to demonstrate this problem.
Run ./dev-windows-select-test and observe select() blocks for the
full timeout, despite the fact that the /dev/windows fd is ready for
reading (and it reported as such as the end of the timeout)
If you run './dev-windows-select-test -skip' to skip the
PeekMessage(), select() returns immediately, indicating the
/dev/windows fd is ready for reading.
[...]
Thanks for the testcase. I examined this and I think I have a
workaround. MSDN states that there's a flag QS_ALLPOSTMESSAGE for
MsgWaitForMultipleObjects, which is not cleared by PeekMessage, if the
wMsgFilterMin and wMsgFilterMax arguments are not both 0. So, what I
did was to add the QS_ALLPOSTMESSAGE flag to the
MsgWaitForMultipleObjects call in select.cc, and to change the
PeekMessage call in select.cc:peek_windows() from
PeekMessage (m, (HWND) h, 0, 0, PM_NOREMOVE)
to
PeekMessage (m, (HWND) h, 1, UINT_MAX, PM_NOREMOVE)
Same in your above test application. This appears to do the trick.
However, I'm not exactly sure if that's a valid fix. Patch below.
Corinna
Index: select.cc
===
RCS file: /cvs/src/src/winsup/cygwin/select.cc,v
retrieving revision 1.160
diff -u -p -r1.160 select.cc
--- select.cc 2 Apr 2010 22:36:44 - 1.160
+++ select.cc 29 Aug 2010 14:16:18 -
@@ -287,7 +287,8 @@ select_stuff::wait (fd_set *readfds, fd_
if (!windows_used)
wait_ret = WaitForMultipleObjects (m, w4, FALSE, ms);
else
- wait_ret = MsgWaitForMultipleObjects (m, w4, FALSE, ms, QS_ALLINPUT);
+ wait_ret = MsgWaitForMultipleObjects (m, w4, FALSE, ms,
+ QS_ALLINPUT | QS_ALLPOSTMESSAGE);
switch (wait_ret)
{
@@ -1531,7 +1532,7 @@ peek_windows (select_record *me, bool)
if (me-read_selected me-read_ready)
return 1;
- if (PeekMessage (m, (HWND) h, 0, 0, PM_NOREMOVE))
+ if (PeekMessage (m, (HWND) h, 1, UINT_MAX, PM_NOREMOVE))
{
me-read_ready = true;
select_printf (window %d(%p) ready, me-fd, me-fh-get_handle ());
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: /dev/windows and select() [was Re: Slow response to keypresses in xorg-server-1.8.0-1]
On Aug 29 16:17, Corinna Vinschen wrote: On Aug 29 14:39, Jon TURNEY wrote: On 08/08/2010 12:04, Andy Koppe wrote: On 7 August 2010 23:07, Jon TURNEY wrote: Hmmm, looking again at the implementation of select(), I don't immediately see that when waiting on /dev/windows, it checks that the message queue has old messages on it before waiting. The MSDN documentation for MsgWaitForMultipleObjects() seems to says that messages which had arrived before the last PeekMessage() etc. aren't considered new and so don't end the wait? [...] Thanks for the testcase. I examined this and I think I have a workaround. MSDN states that there's a flag QS_ALLPOSTMESSAGE for MsgWaitForMultipleObjects, which is not cleared by PeekMessage, if the wMsgFilterMin and wMsgFilterMax arguments are not both 0. So, what I did was to add the QS_ALLPOSTMESSAGE flag to the MsgWaitForMultipleObjects call in select.cc, and to change the PeekMessage call in select.cc:peek_windows() from PeekMessage (m, (HWND) h, 0, 0, PM_NOREMOVE) to PeekMessage (m, (HWND) h, 1, UINT_MAX, PM_NOREMOVE) Same in your above test application. This appears to do the trick. However, I'm not exactly sure if that's a valid fix. Patch below. Hmm, this ignores the potential WM_NULL message, afaics. For some reason, using PeekMessage (m, (HWND) h, 0, UINT_MAX, PM_NOREMOVE) results in MsgWaitForMultipleObjects hanging, too. OTOH, using PeekMessage (m, (HWND) h, 0, 16, PM_NOREMOVE) PeekMessage (m, (HWND) h, 17, UINT_MAX, PM_NOREMOVE) does not. Go figure. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: /dev/windows and select() [was Re: Slow response to keypresses in xorg-server-1.8.0-1]
On Aug 29 16:41, Corinna Vinschen wrote: On Aug 29 16:17, Corinna Vinschen wrote: On Aug 29 14:39, Jon TURNEY wrote: On 08/08/2010 12:04, Andy Koppe wrote: On 7 August 2010 23:07, Jon TURNEY wrote: Hmmm, looking again at the implementation of select(), I don't immediately see that when waiting on /dev/windows, it checks that the message queue has old messages on it before waiting. The MSDN documentation for MsgWaitForMultipleObjects() seems to says that messages which had arrived before the last PeekMessage() etc. aren't considered new and so don't end the wait? [...] Thanks for the testcase. I examined this and I think I have a workaround. MSDN states that there's a flag QS_ALLPOSTMESSAGE for MsgWaitForMultipleObjects, which is not cleared by PeekMessage, if the wMsgFilterMin and wMsgFilterMax arguments are not both 0. So, what I did was to add the QS_ALLPOSTMESSAGE flag to the MsgWaitForMultipleObjects call in select.cc, and to change the PeekMessage call in select.cc:peek_windows() from PeekMessage (m, (HWND) h, 0, 0, PM_NOREMOVE) to PeekMessage (m, (HWND) h, 1, UINT_MAX, PM_NOREMOVE) Same in your above test application. This appears to do the trick. However, I'm not exactly sure if that's a valid fix. Patch below. Hmm, this ignores the potential WM_NULL message, afaics. For some reason, using PeekMessage (m, (HWND) h, 0, UINT_MAX, PM_NOREMOVE) results in MsgWaitForMultipleObjects hanging, too. OTOH, using PeekMessage (m, (HWND) h, 0, 16, PM_NOREMOVE) PeekMessage (m, (HWND) h, 17, UINT_MAX, PM_NOREMOVE) does not. Go figure. Yeah, I realize I'm talking to myself, but this works, too: PeekMessage (m, (HWND) h, 0, UINT_MAX - 1, PM_NOREMOVE) Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: /dev/windows and select() [was Re: Slow response to keypresses in xorg-server-1.8.0-1]
We are listening and learning :-) Dave Sent from my iPad On Aug 29, 2010, at 9:51 AM, Corinna Vinschen corinna-cyg...@cygwin.com wrote: On Aug 29 16:41, Corinna Vinschen wrote: On Aug 29 16:17, Corinna Vinschen wrote: On Aug 29 14:39, Jon TURNEY wrote: On 08/08/2010 12:04, Andy Koppe wrote: On 7 August 2010 23:07, Jon TURNEY wrote: Hmmm, looking again at the implementation of select(), I don't immediately see that when waiting on /dev/windows, it checks that the message queue has old messages on it before waiting. The MSDN documentation for MsgWaitForMultipleObjects() seems to says that messages which had arrived before the last PeekMessage() etc. aren't considered new and so don't end the wait? [...] Thanks for the testcase. I examined this and I think I have a workaround. MSDN states that there's a flag QS_ALLPOSTMESSAGE for MsgWaitForMultipleObjects, which is not cleared by PeekMessage, if the wMsgFilterMin and wMsgFilterMax arguments are not both 0. So, what I did was to add the QS_ALLPOSTMESSAGE flag to the MsgWaitForMultipleObjects call in select.cc, and to change the PeekMessage call in select.cc:peek_windows() from PeekMessage (m, (HWND) h, 0, 0, PM_NOREMOVE) to PeekMessage (m, (HWND) h, 1, UINT_MAX, PM_NOREMOVE) Same in your above test application. This appears to do the trick. However, I'm not exactly sure if that's a valid fix. Patch below. Hmm, this ignores the potential WM_NULL message, afaics. For some reason, using PeekMessage (m, (HWND) h, 0, UINT_MAX, PM_NOREMOVE) results in MsgWaitForMultipleObjects hanging, too. OTOH, using PeekMessage (m, (HWND) h, 0, 16, PM_NOREMOVE) PeekMessage (m, (HWND) h, 17, UINT_MAX, PM_NOREMOVE) does not. Go figure. Yeah, I realize I'm talking to myself, but this works, too: PeekMessage (m, (HWND) h, 0, UINT_MAX - 1, PM_NOREMOVE) Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/ -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: SEGV in gcc 4.3.4 on cygwin 1.7.6-1
On 27/08/2010 09:31, Csaba Raduly wrote: How odd. It seems to crash only with that exact number of parameters. This sounds a lot like a bug I fixed a while ago. Should be OK in 4.5.0 http://gcc.gnu.org/ml/gcc-patches/2010-05/msg02263.html cheers, DaveK -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: BLODA diagnostics
On 27/08/2010 21:44, mike marchywka wrote: On 8/27/10, Baldur Gislason wrote: Hi, what tool is best to track down what BLODA is causing fork failures on my Cygwin installation? There may be a sysinternals tool, I use those to track down open handles that have been a problem on earlier systems. Sysinternals Process Explorer has a mode when it shows you all the DLLs loaded into a process. Any of these that come from security software or other installed applications (i.e. aren't part of the standard windows system DLLs) can give you a clue as to what's causing the BLODA. If that doesn't help, rebaseall might get things going again, if you haven't already tried it. (See /usr/share/doc/Cygwin/rebase-3.0.1.README for usage.) cheers, DaveK -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: BLODA diagnostics
This is exactly what I was looking for, thanks! Looks like the problem was wxvault.dll by Wave Systems. Baldur On Sun, Aug 29, 2010 at 09:28:07PM +0100, Dave Korn wrote: On 27/08/2010 21:44, mike marchywka wrote: On 8/27/10, Baldur Gislason wrote: Hi, what tool is best to track down what BLODA is causing fork failures on my Cygwin installation? There may be a sysinternals tool, I use those to track down open handles that have been a problem on earlier systems. Sysinternals Process Explorer has a mode when it shows you all the DLLs loaded into a process. Any of these that come from security software or other installed applications (i.e. aren't part of the standard windows system DLLs) can give you a clue as to what's causing the BLODA. If that doesn't help, rebaseall might get things going again, if you haven't already tried it. (See /usr/share/doc/Cygwin/rebase-3.0.1.README for usage.) cheers, DaveK -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Linking shared libraries problem
Hi,
I have been trying to port some software from Linux (Scientific
Linux/RedHat) to windows using Cygwin. I have been able to port most of
it with little changes but I encountered a problem when linking shared
libraries. It seems that the chain of dependencies is not included when
linking. Furthermore, ldd does not show the dependency libraries as in
Linux. I have tried both using the import libraries (%.dll.a) and
linking the dll files (%.dll) directly.
I have arranged a small example program that reproduces this effect.
Used Ubuntu 8.04 to and CYGWIN_NT-5.1 version 1.7.6(0.230/5/3)
2010-08-16 16:06 on top of a 32-bits Windows XP Machine to test the
above examples.
x.h:
int add(int a, int b);
x.cpp:
#include x.h
int add(int a, int b) {return a + b;}
y.h:
int sub(int a, int b);
y.cpp:
#include y.h
int sub(int a, int b){return a - b;}
main.cpp:
#include stdio.h
#include x.h
#include y.h
int main()
{
printf(%d\n,add(1,1));
printf(%d\n,sub(2,1));
return 0;
}
Makfile in Linux:
#Compiling
all:
g++ -c x.cpp
g++ -c y.cpp
g++ -shared -Wl,-whole-archive y.o -Wl,-no-whole-archive -o liby.so
g++ -shared -Wl,-whole-archive x.o -Wl,-no-whole-archive -L./ -ly -o
libx.so
g++ -o main main.cpp -L./ -lx
Makefile in Cygwin:
all:
g++ -c x.cpp
g++ -c y.cpp
g++ -shared y.o -Wl,-out-implib=liby.dll.a -Wl,-export-all-symbols
-Wl,-enable-auto-import -Wl,-whole-archive -Wl,-no-whole-archive -o liby.dll
g++ -shared x.o -Wl,-out-implib=libx.dll.a -Wl,-export-all-symbols
-Wl,-enable-auto-import -Wl,-whole-archive -Wl,-no-whole-archive -L./
-ly -o libx.dll
g++ -o main main.cpp -L./ -lx
Linux does not produce any output and the program 'main' works.
Cygwin Output:
/tmp/cc0LNesq.o:main.cpp:(.text+0x4a): undefined reference to `sub(int,
int)'
collect2: ld returned 1 exit status
make: *** [all] Error 1
If I use ldd in Linux for libx.so:
$ ldd libx.so
linux-gate.so.1 = (0xb772f000)
liby.so (0xb7729000)
libstdc++.so.6 = /usr/lib/libstdc++.so.6 (0xb7635000)
libm.so.6 = /lib/tls/i686/cmov/libm.so.6 (0xb75f9000)
libgcc_s.so.1 = /lib/libgcc_s.so.1 (0xb75ee000)
libc.so.6 = /lib/tls/i686/cmov/libc.so.6 (0xb749f000)
/lib/ld-linux.so.2 (0xb773)
and in Cygwin for libx.dll:
$ ldd libx.dll
ntdll.dll = /cygdrive/c/WINDOWS/system32/ntdll.dll (0x7c91)
kernel32.dll = /cygdrive/c/WINDOWS/system32/kernel32.dll (0x7c80)
As you can see, there is no reference to liby.dll. I could add the
library (-ly) directly to the compiling line of main and it works, but
the truth is that it would not be a good approach, since in the software
I'm trying to port, there are several dependent modules, so the last
ones would have an incredibly large list of dependencies.
So, am I doing something wrong? Is there any way to add the dependency
to be shown with ldd or any workaround(maybe a linker flag or something)
to make the above example work?
Thanks in advance.
Best Regards,
Tomas.
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Linking shared libraries problem
On 8/29/2010 7:08 PM, Tomás Staig wrote: Hi, I have been trying to port some software from Linux (Scientific Linux/RedHat) to windows using Cygwin. I have been able to port most of it with little changes but I encountered a problem when linking shared libraries. It seems that the chain of dependencies is not included when linking. Furthermore, ldd does not show the dependency libraries as in Linux. I have tried both using the import libraries (%.dll.a) and linking the dll files (%.dll) directly. I have arranged a small example program that reproduces this effect. Used Ubuntu 8.04 to and CYGWIN_NT-5.1 version 1.7.6(0.230/5/3) 2010-08-16 16:06 on top of a 32-bits Windows XP Machine to test the above examples. snip As you can see, there is no reference to liby.dll. I could add the library (-ly) directly to the compiling line of main and it works, but the truth is that it would not be a good approach, since in the software I'm trying to port, there are several dependent modules, so the last ones would have an incredibly large list of dependencies. So, am I doing something wrong? Is there any way to add the dependency to be shown with ldd or any workaround(maybe a linker flag or something) to make the above example work? The Windows loader requires full resolution at link time. You need to list at least the import libraries for all dependencies if you want the link to succeed. Sorry, that's just the way Windows works. -- Larry Hall http://www.rfk.com RFK Partners, Inc. (508) 893-9779 - RFK Office 216 Dalton Rd. (508) 893-9889 - FAX Holliston, MA 01746 _ A: Yes. Q: Are you sure? A: Because it reverses the logical flow of conversation. Q: Why is top posting annoying in email? -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
1.7.6: error offline installing X11 independently
Hi, everyone Thanks to Jon(X-free ML), I solved the problem of installing boxes.sh, libglade2.0.sh and all the doc*.sh scripts. Now there are still some errors. 1. exim.sh No errors appears in the setup.log.all 2. font*.sh All errors said fc-cache: failed to write cache. 3. plotutilssh Also said failed to write cache. 4. mined.sh OS Registry fail. Thanks in advance. Na Xingyu -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
New: rakudo-star-201007-1, Updated: rakudo-201007_47-1 (aka perl6)
rakudo-star on cygwin is parrot plus rakudo (a perl6 implemention on parrot) plus some new perl6 libraries, docs and libraries and blizkost, a perl5 parrot language which embeds libperl5. Contrary to the upstream rakudo-star release for the masses, this does not include the external parrot or rakudo releases. The external rakudo releases in the future will match the rakudo star release. That's why this rakudo has the version 201007_47, not just 201007, because it's the one from rakudo-star * first package, using external parrot, and an updated rakudo 2010.07-47 * some blizkost and make install patches (already applied upstream) * some testing hacks UPSTREAM ANNOUNCE On behalf of the Rakudo and Perl 6 development teams, I'm happy to announce the July 2010 release of Rakudo Star, a useful and usable distribution of Perl 6. The tarball for the July 2010 release is available from http://github.com/rakudo/star/downloads. Rakudo Star is aimed at early adopters of Perl 6. We know that it still has some bugs, it is far slower than it ought to be, and there are some advanced pieces of the Perl 6 language specification that aren't implemented yet. But Rakudo Perl 6 in its current form is also proving to be viable (and fun) for developing applications and exploring a great new language. These Star releases are intended to make Perl 6 more widely available to programmers, grow the Perl 6 codebase, and gain additional end-user feedback about the Perl 6 language and Rakudo's implementation of it. In the Perl 6 world, we make a distinction between the language (Perl 6) and specific implementations of the language such as Rakudo Perl. Rakudo Star is a distribution that includes release #31 of the Rakudo Perl 6 compiler [1], version 2.6.0 of the Parrot Virtual Machine [2], and various modules, documentation, and other resources collected from the Perl 6 community. We plan to make Rakudo Star releases on a monthly schedule, with occasional special releases in response to important bugfixes or changes. -- Reini Urban = To update your installation, click on the Install Cygwin now link on the http://cygwin.com/ web page. This downloads setup.exe to your system. Once you've downloaded setup.exe, run it and select Editors or Text and then click on the appropriate fields until the above announced version numbers appear if they are not displayed already. If your mirror doesn't yet have the latest version of this package after 24 hours, you can either continue to wait for that site to be updated or you can try to find another mirror. Please send questions or comments to the Cygwin mailing list at: cyg...@cygwin.com If you want to subscribe go to: http://cygwin.com/ml/cygwin/ I would appreciate if you would use this mailing list rather than emailing me directly. This includes ideas and comments about the setup utility or Cygwin in general. If you want to make a point or ask a question the Cygwin mailing list is the appropriate place. -- 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/
