Subject: [clisp-list] win32 gurus?

From: Sam Steingold <[email-masked]>
Date: Sun Jan 27 12:51:02 2002

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 Slobodjuck <[email-masked]>
Date: Sun Jan 27 21:32:02 2002

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:[email-masked]

---

From: Arseny Slobodjuck <[email-masked]>
Date: Mon Jan 28 00:04:02 2002

Hello, Sam,

I make clean, removed all objs, recompiled lisp and problem gone.

---

From: Sam Steingold <[email-masked]>
Date: Mon Jan 28 06:06:05 2002

> * In message <[email-masked]>
> * On the subject of "Re: [clisp-list] win32 gurus?"
> * Sent on Mon, 28 Jan 2002 17:47:34 +1000
> * Honorable Arseny Slobodjuck <[email-masked]> writes:
>
> Hello, Sam,
> 

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: [email-masked] (Thaddeus L. Olczyk)
Date: Mon Jan 28 09:32:05 2002

>        # Do invoke the other handlers.
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.

---

From: Sam Steingold <[email-masked]>
Date: Mon Jan 28 09:59:02 2002

> * In message <[email-masked]>
> * Sent on Mon, 28 Jan 2002 17:31:18 GMT
> * Honorable [email-masked] (Thaddeus L. Olczyk) writes:
>

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 Sabin <[email-masked]>
Date: Mon Jan 28 10:28:06 2002

Sam Steingold <[email-masked]> writes:

> [...]

Like the other poster, I don't see this with current CVS on nt4sp6 or
win2k.

> 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: Arseny Slobodjuck <[email-masked]>
Date: Mon Jan 28 15:35:04 2002

Hello Sam,

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

---

From: [email-masked] (Thaddeus L. Olczyk)
Date: Mon Jan 28 16:38:02 2002

>thread and lets it return gracefully (but unsuccessfully).  No more
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 Sabin <[email-masked]>
Date: Mon Jan 28 19:22:02 2002

> Rather than sending Windows messages around, I prefer to create a

Events are not the same as windows messages.

> 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: [email-masked] (Thaddeus L. Olczyk)
Date: Tue Jan 29 08:43:03 2002

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