From: Sam S. <sd...@gn...> - 2002-01-27 20:50:59
|
when you start CLISP under win32 (or, rather, when _I_ start the current CVS CLISP under nt4sp6 :-) and hit C-c, CLISP dies (as it should), but issues an error message: *** - Win32 error 87 (ERROR_INVALID_PARAMETER): The parameter is incorrect. this message comes from the TerminateThread() call in win32aux.d: local BOOL temp_interrupt_handler(CtrlType) var DWORD CtrlType; { if (CtrlType == CTRL_C_EVENT || CtrlType == CTRL_BREAK_EVENT) { # Could invoke a signal handler at this point.?? if (interruptible_active) { # Set interruptible_active to false, so we won't get here a # second time and try to terminate the same thread twice. interruptible_active = false; # Terminate the interruptible operation, set the exitcode to 1. if (interruptible_socketp) { WSACancelBlockingCall(); } if (!TerminateThread(interruptible_thread,1+CtrlType)) { OS_error(); } } # Don't invoke the other handlers (in particular, the default handler) return true; } else { # Do invoke the other handlers. return false; } } can a win32 guru explain this to me (or, better yet, earn eternal fame by winning a mention in the CLISP ChangeLog by submitting a patch :-) (note that interruptible_thread at that moment does contain a thread created in DoInterruptible()) -- Sam Steingold (http://www.podval.org/~sds) Keep Jerusalem united! <http://www.onejerusalem.org/Petition.asp> Read, think and remember! <http://www.iris.org.il> <http://www.memri.org/> NY survival guide: when crossing a street, mind cars, not streetlights. |
From: Arseny S. <am...@ic...> - 2002-01-28 05:31:38
|
Hello, Sam, Monday, January 28, 2002, 6:49:56 AM, you wrote: Sam> when you start CLISP under win32 (or, rather, when _I_ start the current Sam> CVS CLISP under nt4sp6 :-) and hit C-c, CLISP dies (as it should), but Sam> issues an error message: Sam> *** - Win32 error 87 (ERROR_INVALID_PARAMETER): The parameter is incorrect. Sam> this message comes from the TerminateThread() call in win32aux.d: Seems that it was introduced by last patches. -- Best regards, Arseny mailto:am...@ic... |
From: Arseny S. <am...@ic...> - 2002-01-28 08:03:08
|
Hello, Sam, Monday, January 28, 2002, 6:49:56 AM, you wrote: Sam> when you start CLISP under win32 (or, rather, when _I_ start the current Sam> CVS CLISP under nt4sp6 :-) and hit C-c, CLISP dies (as it should), but Sam> issues an error message: Sam> *** - Win32 error 87 (ERROR_INVALID_PARAMETER): The parameter is incorrect. I make clean, removed all objs, recompiled lisp and problem gone. -- Best regards, Arseny mailto:am...@ic... |
From: Sam S. <sd...@gn...> - 2002-01-28 14:05:46
|
> * In message <124...@ic...> > * On the subject of "Re: [clisp-list] win32 gurus?" > * Sent on Mon, 28 Jan 2002 17:47:34 +1000 > * Honorable Arseny Slobodjuck <am...@ic...> writes: > > Hello, Sam, > > Monday, January 28, 2002, 6:49:56 AM, you wrote: > > Sam> when you start CLISP under win32 (or, rather, when _I_ start the current > Sam> CVS CLISP under nt4sp6 :-) and hit C-c, CLISP dies (as it should), but > Sam> issues an error message: > > Sam> *** - Win32 error 87 (ERROR_INVALID_PARAMETER): The parameter is incorrect. > > I make clean, removed all objs, recompiled lisp and problem gone. this is strange - I observe it even with the released version. (you don't always see the message, but the file location [win32aux.d:99] is always there) -- Sam Steingold (http://www.podval.org/~sds) Keep Jerusalem united! <http://www.onejerusalem.org/Petition.asp> Read, think and remember! <http://www.iris.org.il> <http://www.memri.org/> There is Truth, and its value is T. Or just non-NIL. So 0 is True! |
From: <ol...@in...> - 2002-01-28 17:31:16
|
On 27 Jan 2002 15:49:56 -0500, Sam Steingold <sd...@gn...> wrote: >when you start CLISP under win32 (or, rather, when _I_ start the current >CVS CLISP under nt4sp6 :-) and hit C-c, CLISP dies (as it should), but >issues an error message: > >*** - Win32 error 87 (ERROR_INVALID_PARAMETER): The parameter is = incorrect. > >this message comes from the TerminateThread() call in win32aux.d: > > local BOOL temp_interrupt_handler(CtrlType) > var DWORD CtrlType; > { > if (CtrlType =3D=3D CTRL_C_EVENT || CtrlType =3D=3D = CTRL_BREAK_EVENT) { > # Could invoke a signal handler at this point.?? > if (interruptible_active) { > # Set interruptible_active to false, so we won't get here a > # second time and try to terminate the same thread twice. > interruptible_active =3D false; > # Terminate the interruptible operation, set the exitcode to = 1. > if (interruptible_socketp) { > WSACancelBlockingCall(); > } > if (!TerminateThread(interruptible_thread,1+CtrlType)) { > OS_error(); > } > } > # Don't invoke the other handlers (in particular, the default = handler) > return true; > } else { > # Do invoke the other handlers. > return false; > } > } > Please don't tell me gcc is now using # for comments. Looking up the number the only information I can find is that it is an invalid parameter. Best guess is that the calling thread is dead. The second parameter ( from what I've seen ) does not do anything So it must be the first that is the problem The way to make sure is to store created thread IDs in a vector. Then as each thread dies or is terminated, have it check it's id, and have each remove it's id from the vector. Then have it scream you try to kill a thread that is already dead. >can a win32 guru explain this to me (or, better yet, earn eternal fame >by winning a mention in the CLISP ChangeLog by submitting a patch :-) >(note that interruptible_thread at that moment does contain a thread >created in DoInterruptible()) |
From: Sam S. <sd...@gn...> - 2002-01-28 17:58:14
|
> * In message <3c5...@sm...> > * On the subject of "Re: [clisp-list] win32 gurus?" > * Sent on Mon, 28 Jan 2002 17:31:18 GMT > * Honorable ol...@in... (Thaddeus L. Olczyk) writes: > > The way to make sure is to store created thread IDs in a vector. > Then as each thread dies or is terminated, have it check it's id, > and have each remove it's id from the vector. Then have it scream you > try to kill a thread that is already dead. is this the only way to check whether the thread is alive?! -- Sam Steingold (http://www.podval.org/~sds) Keep Jerusalem united! <http://www.onejerusalem.org/Petition.asp> Read, think and remember! <http://www.iris.org.il> <http://www.memri.org/> "Complete Idiots Guide to Running LINUX Unleashed in a Nutshell for Dummies" |
From: Todd S. <ts...@op...> - 2002-01-28 18:27:54
|
Sam Steingold <sd...@gn...> writes: > when you start CLISP under win32 (or, rather, when _I_ start the current > CVS CLISP under nt4sp6 :-) and hit C-c, CLISP dies (as it should), but > issues an error message: > > *** - Win32 error 87 (ERROR_INVALID_PARAMETER): The parameter is incorrect. > [...] Like the other poster, I don't see this with current CVS on nt4sp6 or win2k. > can a win32 guru explain this to me (or, better yet, earn eternal fame > by winning a mention in the CLISP ChangeLog by submitting a patch :-) > (note that interruptible_thread at that moment does contain a thread > created in DoInterruptible()) As the man page says, TerminateThread is a bad idea, generally. You may be seeing odd side-effects of using it. If used enough, it will eventually ruin your day. The safe way to do what that code wants to do is by having the main thread create an event, which it passes to the child thread. The child thread then does WaitForMultipleObjects on that event and the handle it wants to do IO on. If the ControlHandler is called, it sets that event, which wakes the child thread and lets it return gracefully (but unsuccessfully). No more TerminateThread. Todd |
From: <ol...@in...> - 2002-01-29 00:37:37
|
On 28 Jan 2002 13:27:46 -0500, Todd Sabin <ts...@op...> wrote: >Sam Steingold <sd...@gn...> writes: > >> when you start CLISP under win32 (or, rather, when _I_ start the = current >> CVS CLISP under nt4sp6 :-) and hit C-c, CLISP dies (as it should), but >> issues an error message: >>=20 >> *** - Win32 error 87 (ERROR_INVALID_PARAMETER): The parameter is = incorrect. >> [...] > >Like the other poster, I don't see this with current CVS on nt4sp6 or >win2k. > >> can a win32 guru explain this to me (or, better yet, earn eternal fame >> by winning a mention in the CLISP ChangeLog by submitting a patch :-) >> (note that interruptible_thread at that moment does contain a thread >> created in DoInterruptible()) > >As the man page says, TerminateThread is a bad idea, generally. You >may be seeing odd side-effects of using it. If used enough, it will >eventually ruin your day. The safe way to do what that code wants to >do is by having the main thread create an event, which it passes to >the child thread. The child thread then does WaitForMultipleObjects >on that event and the handle it wants to do IO on. If the >ControlHandler is called, it sets that event, which wakes the child >thread and lets it return gracefully (but unsuccessfully). No more >TerminateThread. > > Rather than sending Windows messages around, I prefer to create a bool valiable that the parent toggles when it wants the child to stop. The infinite loop then terminates and the function called by the thread exits, killing the thread. |
From: Todd S. <ts...@op...> - 2002-01-29 03:21:49
|
ol...@in... (Thaddeus L. Olczyk) writes: > >As the man page says, TerminateThread is a bad idea, generally. You > >may be seeing odd side-effects of using it. If used enough, it will > >eventually ruin your day. The safe way to do what that code wants to > >do is by having the main thread create an event, which it passes to > >the child thread. The child thread then does WaitForMultipleObjects > >on that event and the handle it wants to do IO on. If the > >ControlHandler is called, it sets that event, which wakes the child > >thread and lets it return gracefully (but unsuccessfully). No more > >TerminateThread. > > > Rather than sending Windows messages around, I prefer to create a Events are not the same as windows messages. > bool valiable that the parent toggles when it wants the child to stop. > The infinite loop then terminates and the function called by the > thread exits, killing the thread. If you don't mind busy waiting you can do that, but I try to avoid sending the processor to 100% when not doing anything. Using an event does the same thing you're talking about in principle, but without the busy wait. Todd |
From: Arseny S. <am...@ic...> - 2002-01-28 23:34:51
|
Hello Sam, Tuesday, January 29, 2002, 12:04:31 AM, you wrote: >> Sam> when you start CLISP under win32 (or, rather, when _I_ start the current >> Sam> CVS CLISP under nt4sp6 :-) and hit C-c, CLISP dies (as it should), but >> Sam> issues an error message: >> >> Sam> *** - Win32 error 87 (ERROR_INVALID_PARAMETER): The parameter is incorrect. >> >> I make clean, removed all objs, recompiled lisp and problem gone. Sam> this is strange - I observe it even with the released version. Yep... In 2.27 error persists... -- Best regards, Arseny mailto:am...@ic... |
From: <ol...@in...> - 2002-01-29 16:42:22
|
On 27 Jan 2002 15:49:56 -0500, Sam Steingold <sd...@gn...> wrote: >when you start CLISP under win32 (or, rather, when _I_ start the current >CVS CLISP under nt4sp6 :-) and hit C-c, CLISP dies (as it should), but >issues an error message: > >*** - Win32 error 87 (ERROR_INVALID_PARAMETER): The parameter is = incorrect. > >this message comes from the TerminateThread() call in win32aux.d: > > local BOOL temp_interrupt_handler(CtrlType) > var DWORD CtrlType; > { > if (CtrlType =3D=3D CTRL_C_EVENT || CtrlType =3D=3D = CTRL_BREAK_EVENT) { > # Could invoke a signal handler at this point.?? > if (interruptible_active) { > # Set interruptible_active to false, so we won't get here a > # second time and try to terminate the same thread twice. > interruptible_active =3D false; > # Terminate the interruptible operation, set the exitcode to = 1. > if (interruptible_socketp) { > WSACancelBlockingCall(); > } > if (!TerminateThread(interruptible_thread,1+CtrlType)) { > OS_error(); > } > } > # Don't invoke the other handlers (in particular, the default = handler) > return true; > } else { > # Do invoke the other handlers. > return false; > } > } > >can a win32 guru explain this to me (or, better yet, earn eternal fame >by winning a mention in the CLISP ChangeLog by submitting a patch :-) >(note that interruptible_thread at that moment does contain a thread >created in DoInterruptible()) I do not see this error at all in either the latest CVS update, or in the clisp-2.27 release. OTOH I have a dual processor machine and may be avoiding the race condition that causes the crash. I will try it on another single processor machine later today. |