Re: [twsocket] V6 ThreadDetach #2
The getter could be changed but this could break something elsewhere
I don't know where else this might be impotant. Instead I thought that
V6 is an oportunity to get rid of the old ballast
Yes, indeed. This change would require to check everything again in details.
I can affect any component. This is not as simple as simply remove the line
from the code.
--
[EMAIL PROTECTED]
http://www.overbyte.be
- Original Message -
From: Arno Garrels [EMAIL PROTECTED]
To: ICS support mailing twsocket@elists.org
Sent: Friday, June 23, 2006 9:47 PM
Subject: Re: [twsocket] V6 ThreadDetach #2
Francois PIETTE wrote:
what do you think?
The getter could be changed but this could break something elsewhere
I don't know where else this might be impotant. Instead I thought that
V6 is an oportunity to get rid of the old ballast
depending on the handle being created when needed. Since checking the
handle value is useful to know if attached or not to a thread, maybe
a simple new method IsThreadAttached could be created, just returning
Result := FHandle 0;
Then the offending code could be changed to:
if Assigned(FServer) and FServer.IsThreadAttached then
PostMessage(Server.Handle, Server.FMsg_WM_CLIENT_CLOSED,
That won't help, because that client would never be freed. If the
developer detaches the window handle he becomes responsible for what
was doing, so raising a meaningfull error rather than allocating a new
window in the background is the wayto go, mytwo cents.
btw: IsThreadAttached is probably the best name. It's just was is
passing thru my head now.
--
Contribute to the SSL Effort. Visit
http://www.overbyte.be/eng/ssl.html --
[EMAIL PROTECTED]
http://www.overbyte.be
- Original Message -
From: Arno Garrels [EMAIL PROTECTED]
To: ICS support mailing twsocket@elists.org
Sent: Friday, June 23, 2006 9:12 PM
Subject: Re: [twsocket] V6 ThreadDetach #2
Francois PIETTE wrote:
You get the session closed after calling ThreadDetach ?
Yes, since I'm always stress testing. A client may disconnect at
any time. It would be more straight ahead if the getter would become
a real getter (returning zero if there's no window available) then
checking the return value of PostMessage and raising an exception if
necessary, in this case it propably would be something like
Invalid handle that would make much more sense finding the bug,
what do you think?
---
Arno Garrels [TeamICS]
http://www.overbyte.be/eng/overbyte/teamics.html
--
[EMAIL PROTECTED]
http://www.overbyte.be
- Original Message -
From: Arno Garrels [EMAIL PROTECTED]
To: ICS support mailing twsocket@elists.org
Sent: Friday, June 23, 2006 8:55 AM
Subject: Re: [twsocket] V6 ThreadDetach #2
Already got it! It is as I wrote in my previous mail...
procedure TWSocketClient.TriggerSessionClosed(ErrCode : Word);
begin
if not FSessionClosedFlag then begin
FSessionClosedFlag := TRUE;
if Assigned(FServer) then
PostMessage(Server.Handle, Server.FMsg_WM_CLIENT_CLOSED,
ErrCode,
{$IFDEF CLR}
Integer(IntPtr(Self.HandleGc)));
{$ENDIF}
{$IFDEF WIN32}
LongInt(Self));
{$ENDIF}
inherited TriggerSessionClosed(ErrCode);
end;
end;
A getter that automatically allocates a new window handle is a bad
solution!
Francois Piette wrote:
For debugging purpose, do this:
Create a global public variable in wndcontrol, initialize it to
false.
From your thread exceute, just after threaddetach, set it to
true. From the routine where the window handle is allocated (I
haven't the code
here, I do from my head), add this:
if MyGlobalVar then
OutputDebugString('Got it');
Then place a breakpoint on the OutputDebugString line and run your
program. When (if) the breakpoint is hit, have a look at the stack
trace to understand where it comes from.
Contribute to the SSL Effort. Visit
http://www.overbyte.be/eng/ssl.html --
[EMAIL PROTECTED]
Author of ICS (Internet Component Suite, freeware)
Author of MidWare (Multi-tier framework, freeware)
http://www.overbyte.be
- Original Message -
From: Arno Garrels [EMAIL PROTECTED]
To: ICS support mailing twsocket@elists.org
Sent: Thursday, June 22, 2006 9:37 PM
Subject: Re: [twsocket] V6 ThreadDetach #2
Arno Garrels wrote:
Francois PIETTE wrote:
Not sure what you mean. The problem is that even if you call
ThreadDetach (which is to make the component windowless) you
cannot be sure that the component will not allocate another
window handle somewhere in the background
after that call to ThreadDetach.
I don't see how the component would create another window
handle once ThreadDetach has been called: no event will be
generated anymore. Only the currently executing event will
continue execution ans far as memory serve me well, no event
Re: [twsocket] V6 ThreadDetach #2
For debugging purpose, do this:
Create a global public variable in wndcontrol, initialize it to false.
From your thread exceute, just after threaddetach, set it to true.
From the routine where the window handle is allocated (I haven't the code
here, I do from my head), add this:
if MyGlobalVar then
OutputDebugString('Got it');
Then place a breakpoint on the OutputDebugString line and run your program.
When (if) the breakpoint is hit, have a look at the stack trace to
understand where it comes from.
Contribute to the SSL Effort. Visit http://www.overbyte.be/eng/ssl.html
--
[EMAIL PROTECTED]
Author of ICS (Internet Component Suite, freeware)
Author of MidWare (Multi-tier framework, freeware)
http://www.overbyte.be
- Original Message -
From: Arno Garrels [EMAIL PROTECTED]
To: ICS support mailing twsocket@elists.org
Sent: Thursday, June 22, 2006 9:37 PM
Subject: Re: [twsocket] V6 ThreadDetach #2
Arno Garrels wrote:
Francois PIETTE wrote:
Not sure what you mean. The problem is that even if you call
ThreadDetach (which is to make the component windowless) you cannot
be sure that the component will not allocate another window handle
somewhere in the background
after that call to ThreadDetach.
I don't see how the component would create another window handle once
ThreadDetach has been called: no event will be generated anymore.
Only the currently executing event will continue execution ans far as
memory serve me well, no event recreate a window handle.
Typo, sorry!
Correction:
If so, why do I get this exception? ThreadDetach is executed and
property Handle is set to zero. Nevertheless the exeption is raised.
So a window handle must have been allocated after the call to ThreadDetach
somewhere. Please tell me what might be wrong with the very simple
code I posted before. There's no deadlock, sure. Especially not if
you exchange WaitFor by WaitForSingleObject. Also, as far as I can
see entire methode ThreadDetach is blocking, so the thread shouldn't
signal before the window handle was set to zero, right?
--
To unsubscribe or change your settings for TWSocket mailing list
please goto http://www.elists.org/mailman/listinfo/twsocket
Visit our website at http://www.overbyte.be
--
To unsubscribe or change your settings for TWSocket mailing list
please goto http://www.elists.org/mailman/listinfo/twsocket
Visit our website at http://www.overbyte.be
Re: [twsocket] V6 ThreadDetach #2
Already got it! It is as I wrote in my previous mail...
procedure TWSocketClient.TriggerSessionClosed(ErrCode : Word);
begin
if not FSessionClosedFlag then begin
FSessionClosedFlag := TRUE;
if Assigned(FServer) then
PostMessage(Server.Handle, Server.FMsg_WM_CLIENT_CLOSED, ErrCode,
{$IFDEF CLR}
Integer(IntPtr(Self.HandleGc)));
{$ENDIF}
{$IFDEF WIN32}
LongInt(Self));
{$ENDIF}
inherited TriggerSessionClosed(ErrCode);
end;
end;
A getter that automatically allocates a new window handle is a bad solution!
Francois Piette wrote:
For debugging purpose, do this:
Create a global public variable in wndcontrol, initialize it to false.
From your thread exceute, just after threaddetach, set it to true.
From the routine where the window handle is allocated (I haven't the
code
here, I do from my head), add this:
if MyGlobalVar then
OutputDebugString('Got it');
Then place a breakpoint on the OutputDebugString line and run your
program. When (if) the breakpoint is hit, have a look at the stack
trace to understand where it comes from.
Contribute to the SSL Effort. Visit
http://www.overbyte.be/eng/ssl.html --
[EMAIL PROTECTED]
Author of ICS (Internet Component Suite, freeware)
Author of MidWare (Multi-tier framework, freeware)
http://www.overbyte.be
- Original Message -
From: Arno Garrels [EMAIL PROTECTED]
To: ICS support mailing twsocket@elists.org
Sent: Thursday, June 22, 2006 9:37 PM
Subject: Re: [twsocket] V6 ThreadDetach #2
Arno Garrels wrote:
Francois PIETTE wrote:
Not sure what you mean. The problem is that even if you call
ThreadDetach (which is to make the component windowless) you
cannot be sure that the component will not allocate another
window handle somewhere in the background
after that call to ThreadDetach.
I don't see how the component would create another window handle
once ThreadDetach has been called: no event will be generated
anymore. Only the currently executing event will continue
execution ans far as memory serve me well, no event recreate a
window handle.
Typo, sorry!
Correction:
If so, why do I get this exception? ThreadDetach is executed and
property Handle is set to zero. Nevertheless the exeption is raised.
So a window handle must have been allocated after the call to
ThreadDetach somewhere. Please tell me what might be wrong with the
very simple code I posted before. There's no deadlock, sure.
Especially not if you exchange WaitFor by WaitForSingleObject. Also,
as far as I can see entire methode ThreadDetach is blocking, so the
thread shouldn't signal before the window handle was set to zero,
right? --
To unsubscribe or change your settings for TWSocket mailing list
please goto http://www.elists.org/mailman/listinfo/twsocket
Visit our website at http://www.overbyte.be
--
To unsubscribe or change your settings for TWSocket mailing list
please goto http://www.elists.org/mailman/listinfo/twsocket
Visit our website at http://www.overbyte.be
Re: [twsocket] V6 ThreadDetach #2
Francois PIETTE wrote:
You get the session closed after calling ThreadDetach ?
Yes, since I'm always stress testing. A client may disconnect at
any time. It would be more straight ahead if the getter would become
a real getter (returning zero if there's no window available) then
checking the return value of PostMessage and raising an exception if
necessary, in this case it propably would be something like
Invalid handle that would make much more sense finding the bug,
what do you think?
---
Arno Garrels [TeamICS]
http://www.overbyte.be/eng/overbyte/teamics.html
--
[EMAIL PROTECTED]
http://www.overbyte.be
- Original Message -
From: Arno Garrels [EMAIL PROTECTED]
To: ICS support mailing twsocket@elists.org
Sent: Friday, June 23, 2006 8:55 AM
Subject: Re: [twsocket] V6 ThreadDetach #2
Already got it! It is as I wrote in my previous mail...
procedure TWSocketClient.TriggerSessionClosed(ErrCode : Word);
begin
if not FSessionClosedFlag then begin
FSessionClosedFlag := TRUE;
if Assigned(FServer) then
PostMessage(Server.Handle, Server.FMsg_WM_CLIENT_CLOSED,
ErrCode,
{$IFDEF CLR}
Integer(IntPtr(Self.HandleGc)));
{$ENDIF}
{$IFDEF WIN32}
LongInt(Self));
{$ENDIF}
inherited TriggerSessionClosed(ErrCode);
end;
end;
A getter that automatically allocates a new window handle is a bad
solution!
Francois Piette wrote:
For debugging purpose, do this:
Create a global public variable in wndcontrol, initialize it to
false.
From your thread exceute, just after threaddetach, set it to true.
From the routine where the window handle is allocated (I haven't
the code
here, I do from my head), add this:
if MyGlobalVar then
OutputDebugString('Got it');
Then place a breakpoint on the OutputDebugString line and run your
program. When (if) the breakpoint is hit, have a look at the stack
trace to understand where it comes from.
Contribute to the SSL Effort. Visit
http://www.overbyte.be/eng/ssl.html --
[EMAIL PROTECTED]
Author of ICS (Internet Component Suite, freeware)
Author of MidWare (Multi-tier framework, freeware)
http://www.overbyte.be
- Original Message -
From: Arno Garrels [EMAIL PROTECTED]
To: ICS support mailing twsocket@elists.org
Sent: Thursday, June 22, 2006 9:37 PM
Subject: Re: [twsocket] V6 ThreadDetach #2
Arno Garrels wrote:
Francois PIETTE wrote:
Not sure what you mean. The problem is that even if you call
ThreadDetach (which is to make the component windowless) you
cannot be sure that the component will not allocate another
window handle somewhere in the background
after that call to ThreadDetach.
I don't see how the component would create another window handle
once ThreadDetach has been called: no event will be generated
anymore. Only the currently executing event will continue
execution ans far as memory serve me well, no event recreate a
window handle.
Typo, sorry!
Correction:
If so, why do I get this exception? ThreadDetach is executed and
property Handle is set to zero. Nevertheless the exeption is
raised. So a window handle must have been allocated after the call
to ThreadDetach somewhere. Please tell me what might be wrong with
the very simple code I posted before. There's no deadlock, sure.
Especially not if you exchange WaitFor by WaitForSingleObject.
Also, as far as I can see entire methode ThreadDetach is blocking,
so the thread shouldn't signal before the window handle was set to
zero, right? --
To unsubscribe or change your settings for TWSocket mailing list
please goto http://www.elists.org/mailman/listinfo/twsocket
Visit our website at http://www.overbyte.be
--
To unsubscribe or change your settings for TWSocket mailing list
please goto http://www.elists.org/mailman/listinfo/twsocket
Visit our website at http://www.overbyte.be
--
To unsubscribe or change your settings for TWSocket mailing list
please goto http://www.elists.org/mailman/listinfo/twsocket
Visit our website at http://www.overbyte.be
Re: [twsocket] V6 ThreadDetach #2
what do you think?
The getter could be changed but this could break something elsewhere
depending on the handle being created when needed. Since checking the handle
value is useful to know if attached or not to a thread, maybe a simple new
method IsThreadAttached could be created, just returning Result := FHandle
0;
Then the offending code could be changed to:
if Assigned(FServer) and FServer.IsThreadAttached then
PostMessage(Server.Handle, Server.FMsg_WM_CLIENT_CLOSED,
btw: IsThreadAttached is probably the best name. It's just was is passing
thru my head now.
--
Contribute to the SSL Effort. Visit http://www.overbyte.be/eng/ssl.html
--
[EMAIL PROTECTED]
http://www.overbyte.be
- Original Message -
From: Arno Garrels [EMAIL PROTECTED]
To: ICS support mailing twsocket@elists.org
Sent: Friday, June 23, 2006 9:12 PM
Subject: Re: [twsocket] V6 ThreadDetach #2
Francois PIETTE wrote:
You get the session closed after calling ThreadDetach ?
Yes, since I'm always stress testing. A client may disconnect at
any time. It would be more straight ahead if the getter would become
a real getter (returning zero if there's no window available) then
checking the return value of PostMessage and raising an exception if
necessary, in this case it propably would be something like
Invalid handle that would make much more sense finding the bug,
what do you think?
---
Arno Garrels [TeamICS]
http://www.overbyte.be/eng/overbyte/teamics.html
--
[EMAIL PROTECTED]
http://www.overbyte.be
- Original Message -
From: Arno Garrels [EMAIL PROTECTED]
To: ICS support mailing twsocket@elists.org
Sent: Friday, June 23, 2006 8:55 AM
Subject: Re: [twsocket] V6 ThreadDetach #2
Already got it! It is as I wrote in my previous mail...
procedure TWSocketClient.TriggerSessionClosed(ErrCode : Word);
begin
if not FSessionClosedFlag then begin
FSessionClosedFlag := TRUE;
if Assigned(FServer) then
PostMessage(Server.Handle, Server.FMsg_WM_CLIENT_CLOSED,
ErrCode,
{$IFDEF CLR}
Integer(IntPtr(Self.HandleGc)));
{$ENDIF}
{$IFDEF WIN32}
LongInt(Self));
{$ENDIF}
inherited TriggerSessionClosed(ErrCode);
end;
end;
A getter that automatically allocates a new window handle is a bad
solution!
Francois Piette wrote:
For debugging purpose, do this:
Create a global public variable in wndcontrol, initialize it to
false.
From your thread exceute, just after threaddetach, set it to true.
From the routine where the window handle is allocated (I haven't
the code
here, I do from my head), add this:
if MyGlobalVar then
OutputDebugString('Got it');
Then place a breakpoint on the OutputDebugString line and run your
program. When (if) the breakpoint is hit, have a look at the stack
trace to understand where it comes from.
Contribute to the SSL Effort. Visit
http://www.overbyte.be/eng/ssl.html --
[EMAIL PROTECTED]
Author of ICS (Internet Component Suite, freeware)
Author of MidWare (Multi-tier framework, freeware)
http://www.overbyte.be
- Original Message -
From: Arno Garrels [EMAIL PROTECTED]
To: ICS support mailing twsocket@elists.org
Sent: Thursday, June 22, 2006 9:37 PM
Subject: Re: [twsocket] V6 ThreadDetach #2
Arno Garrels wrote:
Francois PIETTE wrote:
Not sure what you mean. The problem is that even if you call
ThreadDetach (which is to make the component windowless) you
cannot be sure that the component will not allocate another
window handle somewhere in the background
after that call to ThreadDetach.
I don't see how the component would create another window handle
once ThreadDetach has been called: no event will be generated
anymore. Only the currently executing event will continue
execution ans far as memory serve me well, no event recreate a
window handle.
Typo, sorry!
Correction:
If so, why do I get this exception? ThreadDetach is executed and
property Handle is set to zero. Nevertheless the exeption is
raised. So a window handle must have been allocated after the call
to ThreadDetach somewhere. Please tell me what might be wrong with
the very simple code I posted before. There's no deadlock, sure.
Especially not if you exchange WaitFor by WaitForSingleObject.
Also, as far as I can see entire methode ThreadDetach is blocking,
so the thread shouldn't signal before the window handle was set to
zero, right? --
To unsubscribe or change your settings for TWSocket mailing list
please goto http://www.elists.org/mailman/listinfo/twsocket
Visit our website at http://www.overbyte.be
--
To unsubscribe or change your settings for TWSocket mailing list
please goto http://www.elists.org/mailman/listinfo/twsocket
Visit our website at http://www.overbyte.be
--
To unsubscribe or change your settings for TWSocket mailing list
please goto
Re: [twsocket] V6 ThreadDetach #2
If you set a breakpoint on FServer.ThreadDetach, do you get a hit on it when stopping the server ? And when you single step into the code, is the handle actually set to 0 ? -- [EMAIL PROTECTED] http://www.overbyte.be - Original Message - From: Arno Garrels [EMAIL PROTECTED] To: ICS support mailing twsocket@elists.org Sent: Thursday, June 22, 2006 3:20 PM Subject: [twsocket] V6 ThreadDetach #2 I have the following problem in V6: constructor TListenThread.Create(AServer: TMtWSocketServer); begin inherited Create(True); FreeOnTerminate := FALSE; FServer := AServer; FServer.ThreadDetach; end; procedure TListenThread.Execute; begin FServer.ThreadAttach; FServer.Listen; FServer.MessageLoop; FServer.Close; FServer.ThreadDetach; end; procedure TForm1.btnStartClick(Sender: TObject); begin //properties of Server1 are assigned FListenThread := TListenThread.Create(Server1); FListenThread.Resume; end; procedure TForm1.btnStopClick(Sender: TObject); begin PostMessage(Server1.Handle, WM_QUIT, 0, 0); FListenThread.WaitFor; FreeAndNil(FListenThread); = here the Server1.Handle is not 0! Server1.ThreadAttach; // so raises an exception end; Any idea? --- Arno Garrels [TeamICS] http://www.overbyte.be/eng/overbyte/teamics.html -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] V6 ThreadDetach #2
Francois Piette wrote: If you set a breakpoint on FServer.ThreadDetach, do you get a hit on it when stopping the server ? And when you single step into the code, is the handle actually set to 0 ? -- Yes, it is set to 0! [EMAIL PROTECTED] http://www.overbyte.be - Original Message - From: Arno Garrels [EMAIL PROTECTED] To: ICS support mailing twsocket@elists.org Sent: Thursday, June 22, 2006 3:20 PM Subject: [twsocket] V6 ThreadDetach #2 I have the following problem in V6: constructor TListenThread.Create(AServer: TMtWSocketServer); begin inherited Create(True); FreeOnTerminate := FALSE; FServer := AServer; FServer.ThreadDetach; end; procedure TListenThread.Execute; begin FServer.ThreadAttach; FServer.Listen; FServer.MessageLoop; FServer.Close; FServer.ThreadDetach; end; procedure TForm1.btnStartClick(Sender: TObject); begin //properties of Server1 are assigned FListenThread := TListenThread.Create(Server1); FListenThread.Resume; end; procedure TForm1.btnStopClick(Sender: TObject); begin PostMessage(Server1.Handle, WM_QUIT, 0, 0); FListenThread.WaitFor; FreeAndNil(FListenThread); = here the Server1.Handle is not 0! Server1.ThreadAttach; // so raises an exception end; Any idea? --- Arno Garrels [TeamICS] http://www.overbyte.be/eng/overbyte/teamics.html -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] V6 ThreadDetach #2
I had the same problem. In my case, I had to post a message before ending the thread. There was pending messages that called GetHandle which called AllocateHwnd()!!! Regards, SZ - Original Message - From: Arno Garrels [EMAIL PROTECTED] To: ICS support mailing twsocket@elists.org Sent: Thursday, June 22, 2006 4:20 PM Subject: [twsocket] V6 ThreadDetach #2 :I have the following problem in V6: : : constructor TListenThread.Create(AServer: TMtWSocketServer); : begin :inherited Create(True); :FreeOnTerminate := FALSE; :FServer := AServer; :FServer.ThreadDetach; : end; : : procedure TListenThread.Execute; : begin :FServer.ThreadAttach; :FServer.Listen; :FServer.MessageLoop; :FServer.Close; :FServer.ThreadDetach; : end; : : procedure TForm1.btnStartClick(Sender: TObject); : begin ://properties of Server1 are assigned :FListenThread := TListenThread.Create(Server1); :FListenThread.Resume; : end; : : : procedure TForm1.btnStopClick(Sender: TObject); : begin :PostMessage(Server1.Handle, WM_QUIT, 0, 0); :FListenThread.WaitFor; :FreeAndNil(FListenThread); : = here the Server1.Handle is not 0! :Server1.ThreadAttach; // so raises an exception : end; : : Any idea? : : --- : Arno Garrels [TeamICS] : http://www.overbyte.be/eng/overbyte/teamics.html : : -- : To unsubscribe or change your settings for TWSocket mailing list : please goto http://www.elists.org/mailman/listinfo/twsocket : Visit our website at http://www.overbyte.be -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] V6 ThreadDetach #2
Fastream Technologies wrote: I had the same problem. In my case, I had to post a message before ending the thread. There was pending messages that called GetHandle which called AllocateHwnd()!!! GetHandle isn't called in my case. There are no connections, I'm just pressing btnStart and btnStop. Regards, SZ - Original Message - From: Arno Garrels [EMAIL PROTECTED] To: ICS support mailing twsocket@elists.org Sent: Thursday, June 22, 2006 4:20 PM Subject: [twsocket] V6 ThreadDetach #2 I have the following problem in V6: constructor TListenThread.Create(AServer: TMtWSocketServer); begin inherited Create(True); FreeOnTerminate := FALSE; FServer := AServer; FServer.ThreadDetach; end; procedure TListenThread.Execute; begin FServer.ThreadAttach; FServer.Listen; FServer.MessageLoop; FServer.Close; FServer.ThreadDetach; end; procedure TForm1.btnStartClick(Sender: TObject); begin //properties of Server1 are assigned FListenThread := TListenThread.Create(Server1); FListenThread.Resume; end; procedure TForm1.btnStopClick(Sender: TObject); begin PostMessage(Server1.Handle, WM_QUIT, 0, 0); FListenThread.WaitFor; FreeAndNil(FListenThread); = here the Server1.Handle is not 0! Server1.ThreadAttach; // so raises an exception end; Any idea? --- Arno Garrels [TeamICS] http://www.overbyte.be/eng/overbyte/teamics.html -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] V6 ThreadDetach #2
Arno Garrels wrote: Fastream Technologies wrote: I had the same problem. In my case, I had to post a message before ending the thread. There was pending messages that called GetHandle which called AllocateHwnd()!!! GetHandle isn't called in my case. There are no connections, I'm just pressing btnStart and btnStop. I played a bit mainly steping thru the code, then reverted changes back to the code I posted, and now the error is gone, very strange! Regards, SZ - Original Message - From: Arno Garrels [EMAIL PROTECTED] To: ICS support mailing twsocket@elists.org Sent: Thursday, June 22, 2006 4:20 PM Subject: [twsocket] V6 ThreadDetach #2 I have the following problem in V6: constructor TListenThread.Create(AServer: TMtWSocketServer); begin inherited Create(True); FreeOnTerminate := FALSE; FServer := AServer; FServer.ThreadDetach; end; procedure TListenThread.Execute; begin FServer.ThreadAttach; FServer.Listen; FServer.MessageLoop; FServer.Close; FServer.ThreadDetach; end; procedure TForm1.btnStartClick(Sender: TObject); begin //properties of Server1 are assigned FListenThread := TListenThread.Create(Server1); FListenThread.Resume; end; procedure TForm1.btnStopClick(Sender: TObject); begin PostMessage(Server1.Handle, WM_QUIT, 0, 0); FListenThread.WaitFor; FreeAndNil(FListenThread); = here the Server1.Handle is not 0! Server1.ThreadAttach; // so raises an exception end; Any idea? --- Arno Garrels [TeamICS] http://www.overbyte.be/eng/overbyte/teamics.html -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] V6 ThreadDetach #2
Fastream Technologies wrote: I had the same problem. In my case, I had to post a message before ending the thread. There was pending messages that called GetHandle which called AllocateHwnd()!!! My problem still persists, sometimes the exception Cannot attach when not detached is raised. However I cannot imagine that exchanging WaitFor by your method can change anything basically. Probably the strange GetHandle() getter is the culprid? Regards, SZ - Original Message - From: Arno Garrels [EMAIL PROTECTED] To: ICS support mailing twsocket@elists.org Sent: Thursday, June 22, 2006 4:20 PM Subject: [twsocket] V6 ThreadDetach #2 I have the following problem in V6: constructor TListenThread.Create(AServer: TMtWSocketServer); begin inherited Create(True); FreeOnTerminate := FALSE; FServer := AServer; FServer.ThreadDetach; end; procedure TListenThread.Execute; begin FServer.ThreadAttach; FServer.Listen; FServer.MessageLoop; FServer.Close; FServer.ThreadDetach; end; procedure TForm1.btnStartClick(Sender: TObject); begin //properties of Server1 are assigned FListenThread := TListenThread.Create(Server1); FListenThread.Resume; end; procedure TForm1.btnStopClick(Sender: TObject); begin PostMessage(Server1.Handle, WM_QUIT, 0, 0); FListenThread.WaitFor; FreeAndNil(FListenThread); = here the Server1.Handle is not 0! Server1.ThreadAttach; // so raises an exception end; Any idea? --- Arno Garrels [TeamICS] http://www.overbyte.be/eng/overbyte/teamics.html -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] V6 ThreadDetach #2
This is surely not the problem, but WaitFor should be avoided when possible. It is known to create deadlocks. -- Contribute to the SSL Effort. Visit http://www.overbyte.be/eng/ssl.html -- [EMAIL PROTECTED] http://www.overbyte.be - Original Message - From: Arno Garrels [EMAIL PROTECTED] To: ICS support mailing twsocket@elists.org Sent: Thursday, June 22, 2006 6:59 PM Subject: Re: [twsocket] V6 ThreadDetach #2 Fastream Technologies wrote: I had the same problem. In my case, I had to post a message before ending the thread. There was pending messages that called GetHandle which called AllocateHwnd()!!! My problem still persists, sometimes the exception Cannot attach when not detached is raised. However I cannot imagine that exchanging WaitFor by your method can change anything basically. Probably the strange GetHandle() getter is the culprid? Regards, SZ - Original Message - From: Arno Garrels [EMAIL PROTECTED] To: ICS support mailing twsocket@elists.org Sent: Thursday, June 22, 2006 4:20 PM Subject: [twsocket] V6 ThreadDetach #2 I have the following problem in V6: constructor TListenThread.Create(AServer: TMtWSocketServer); begin inherited Create(True); FreeOnTerminate := FALSE; FServer := AServer; FServer.ThreadDetach; end; procedure TListenThread.Execute; begin FServer.ThreadAttach; FServer.Listen; FServer.MessageLoop; FServer.Close; FServer.ThreadDetach; end; procedure TForm1.btnStartClick(Sender: TObject); begin //properties of Server1 are assigned FListenThread := TListenThread.Create(Server1); FListenThread.Resume; end; procedure TForm1.btnStopClick(Sender: TObject); begin PostMessage(Server1.Handle, WM_QUIT, 0, 0); FListenThread.WaitFor; FreeAndNil(FListenThread); = here the Server1.Handle is not 0! Server1.ThreadAttach; // so raises an exception end; Any idea? --- Arno Garrels [TeamICS] http://www.overbyte.be/eng/overbyte/teamics.html -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] V6 ThreadDetach #2
and if you replace waitfor it with a ThreadTerminated construction, maybe thats easier? I used waitfor only once and had deadlock issues which caused me to removed asap :-) - Original Message - From: Arno Garrels [EMAIL PROTECTED] To: ICS support mailing twsocket@elists.org Sent: Thursday, June 22, 2006 8:01 PM Subject: Re: [twsocket] V6 ThreadDetach #2 Francois PIETTE wrote: This is surely not the problem, but WaitFor should be avoided when possible. It is known to create deadlocks. I already exchanged it by a simple WaitForSingleObject(ThreadHandle) since WaitFor is know to make trouble, anyway the problem persists. -- Contribute to the SSL Effort. Visit http://www.overbyte.be/eng/ssl.html -- [EMAIL PROTECTED] http://www.overbyte.be - Original Message - From: Arno Garrels [EMAIL PROTECTED] To: ICS support mailing twsocket@elists.org Sent: Thursday, June 22, 2006 6:59 PM Subject: Re: [twsocket] V6 ThreadDetach #2 Fastream Technologies wrote: I had the same problem. In my case, I had to post a message before ending the thread. There was pending messages that called GetHandle which called AllocateHwnd()!!! My problem still persists, sometimes the exception Cannot attach when not detached is raised. However I cannot imagine that exchanging WaitFor by your method can change anything basically. Probably the strange GetHandle() getter is the culprid? Regards, SZ - Original Message - From: Arno Garrels [EMAIL PROTECTED] To: ICS support mailing twsocket@elists.org Sent: Thursday, June 22, 2006 4:20 PM Subject: [twsocket] V6 ThreadDetach #2 I have the following problem in V6: constructor TListenThread.Create(AServer: TMtWSocketServer); begin inherited Create(True); FreeOnTerminate := FALSE; FServer := AServer; FServer.ThreadDetach; end; procedure TListenThread.Execute; begin FServer.ThreadAttach; FServer.Listen; FServer.MessageLoop; FServer.Close; FServer.ThreadDetach; end; procedure TForm1.btnStartClick(Sender: TObject); begin //properties of Server1 are assigned FListenThread := TListenThread.Create(Server1); FListenThread.Resume; end; procedure TForm1.btnStopClick(Sender: TObject); begin PostMessage(Server1.Handle, WM_QUIT, 0, 0); FListenThread.WaitFor; FreeAndNil(FListenThread); = here the Server1.Handle is not 0! Server1.ThreadAttach; // so raises an exception end; Any idea? --- Arno Garrels [TeamICS] http://www.overbyte.be/eng/overbyte/teamics.html -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] V6 ThreadDetach #2
Frans van Daalen wrote: and if you replace waitfor it with a ThreadTerminated construction, maybe thats easier? I used waitfor only once and had deadlock issues which caused me to removed asap :-) Not sure what you mean. The problem is that even if you call ThreadDetach (which is to make the component windowless) you cannot be sure that the component will not allocate another window handle somewhere in the background after that call to ThreadDetach. - Original Message - From: Arno Garrels [EMAIL PROTECTED] To: ICS support mailing twsocket@elists.org Sent: Thursday, June 22, 2006 8:01 PM Subject: Re: [twsocket] V6 ThreadDetach #2 Francois PIETTE wrote: This is surely not the problem, but WaitFor should be avoided when possible. It is known to create deadlocks. I already exchanged it by a simple WaitForSingleObject(ThreadHandle) since WaitFor is know to make trouble, anyway the problem persists. -- Contribute to the SSL Effort. Visit http://www.overbyte.be/eng/ssl.html -- [EMAIL PROTECTED] http://www.overbyte.be - Original Message - From: Arno Garrels [EMAIL PROTECTED] To: ICS support mailing twsocket@elists.org Sent: Thursday, June 22, 2006 6:59 PM Subject: Re: [twsocket] V6 ThreadDetach #2 Fastream Technologies wrote: I had the same problem. In my case, I had to post a message before ending the thread. There was pending messages that called GetHandle which called AllocateHwnd()!!! My problem still persists, sometimes the exception Cannot attach when not detached is raised. However I cannot imagine that exchanging WaitFor by your method can change anything basically. Probably the strange GetHandle() getter is the culprid? Regards, SZ - Original Message - From: Arno Garrels [EMAIL PROTECTED] To: ICS support mailing twsocket@elists.org Sent: Thursday, June 22, 2006 4:20 PM Subject: [twsocket] V6 ThreadDetach #2 I have the following problem in V6: constructor TListenThread.Create(AServer: TMtWSocketServer); begin inherited Create(True); FreeOnTerminate := FALSE; FServer := AServer; FServer.ThreadDetach; end; procedure TListenThread.Execute; begin FServer.ThreadAttach; FServer.Listen; FServer.MessageLoop; FServer.Close; FServer.ThreadDetach; end; procedure TForm1.btnStartClick(Sender: TObject); begin //properties of Server1 are assigned FListenThread := TListenThread.Create(Server1); FListenThread.Resume; end; procedure TForm1.btnStopClick(Sender: TObject); begin PostMessage(Server1.Handle, WM_QUIT, 0, 0); FListenThread.WaitFor; FreeAndNil(FListenThread); = here the Server1.Handle is not 0! Server1.ThreadAttach; // so raises an exception end; Any idea? --- Arno Garrels [TeamICS] http://www.overbyte.be/eng/overbyte/teamics.html -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] V6 ThreadDetach #2
Not sure what you mean. The problem is that even if you call ThreadDetach (which is to make the component windowless) you cannot be sure that the component will not allocate another window handle somewhere in the background after that call to ThreadDetach. I don't see how the component would create another window handle once ThreadDetach has been called: no event will be generated anymore. Only the currently executing event will continue execution ans far as memory serve me well, no event recreate a window handle. -- Contribute to the SSL Effort. Visit http://www.overbyte.be/eng/ssl.html -- [EMAIL PROTECTED] http://www.overbyte.be -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] V6 ThreadDetach #2
Francois PIETTE wrote: Not sure what you mean. The problem is that even if you call ThreadDetach (which is to make the component windowless) you cannot be sure that the component will not allocate another window handle somewhere in the background after that call to ThreadDetach. I don't see how the component would create another window handle once ThreadDetach has been called: no event will be generated anymore. Only the currently executing event will continue execution ans far as memory serve me well, no event recreate a window handle. If so, why do I get this exception? ThreadDetach is executed and property Handle is set to zero. Nevertheless the exeption is raised. So a window handle must be allocated after the call to ThreadAttach somewhere. Please tell me what might be wrong with the very simple code I posted before. There's no deadlock, sure. Especially not if you exchange WaitFor by WaitForSingleObject. Also, as far as I can see entire methode ThreadDetach is blocking, so the thread shouldn't signal before the handle was set to zero, right? -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] V6 ThreadDetach #2
Arno Garrels wrote: Francois PIETTE wrote: Not sure what you mean. The problem is that even if you call ThreadDetach (which is to make the component windowless) you cannot be sure that the component will not allocate another window handle somewhere in the background after that call to ThreadDetach. I don't see how the component would create another window handle once ThreadDetach has been called: no event will be generated anymore. Only the currently executing event will continue execution ans far as memory serve me well, no event recreate a window handle. Typo, sorry! Correction: If so, why do I get this exception? ThreadDetach is executed and property Handle is set to zero. Nevertheless the exeption is raised. So a window handle must have been allocated after the call to ThreadDetach somewhere. Please tell me what might be wrong with the very simple code I posted before. There's no deadlock, sure. Especially not if you exchange WaitFor by WaitForSingleObject. Also, as far as I can see entire methode ThreadDetach is blocking, so the thread shouldn't signal before the window handle was set to zero, right? -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
