[twsocket] Test Exception in WSocket
Hello,
In the WSocket.pas code below (v6):
procedure TCustomWSocket.WndProc(var MsgRec: TMessage);
begin
try
with MsgRec do begin
if Msg = FMsg_WM_ASYNCSELECT then
WMASyncSelect(MsgRec)
else if Msg = FMsg_WM_ASYNCGETHOSTBYNAME then
WMAsyncGetHostByName(MsgRec)
else if Msg = FMsg_WM_ASYNCGETHOSTBYADDR then
WMAsyncGetHostByAddr(MsgRec)
else if Msg = FMsg_WM_CLOSE_DELAYED then
WMCloseDelayed(MsgRec)
//else if Msg = FMsg_WM_WSOCKET_RELEASE then
//WMRelease(MsgRec)
else if Msg = FMsg_WM_TRIGGER_EXCEPTION then
{ This is useful to check for background
}
{ In your application, use following code to test your
handler }
{ PostMessage(WSocket1.Handle, WM_TRIGGER_EXCEPTION, 0,
}
raise ESocketException.Create('Test exception in WSocket')
else
inherited WndProc(MsgRec);
//Result := DefWindowProc(Handle, Msg, wParam, LParam);
end;
except
on E:Exception do
HandleBackGroundException(E);
end;
end;
I randomly get the test exception fired in my code. It used to give AV but
now after some more work, it now gives this. I do not have any code such as
PostMessage(WSocket1.Handle, WM_TRIGGER_EXCEPTION, 0, 0);
as stated in the code. How can I understand which line of code or sequence
causes the problem?
Best Regards,
SubZero
--
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] Interesting multithreading issue: race condition whentriggering an event handler
Francois PIETTE wrote: I've found an interesting multithreading issue which is related not The solution is to rewrite the procedure as follow: Line1: procedure TMyComponent.TriggerMyEvent(MyArg : Integer); Line2: var Line3: TMyEventProc EventProc; Line4: begin Line5: EventProc := OnMyEvent; Line6: if Assigned(EventProc) then Line7: EventProc(Self, MyArg); Line8: end; Saving the event pointer in line5 make sure that it is still valid in the case a thread switch between Line 6 and 7 occur and the OnMyEvent is set to nil by the other thread. Interesting, isn't it ? I think it's better/faster than having critical sections for all triggers, do you plan to change all ICS triggers accordingly? --- 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
Re: [twsocket] Test Exception in WSocket
Fastream Technologies wrote:
I randomly get the test exception fired in my code.
Make sure your custom messages are in a range above
WH_MAX_MSG!!
It used to give
AV but now after some more work, it now gives this. I do not have any
code such as
PostMessage(WSocket1.Handle, WM_TRIGGER_EXCEPTION, 0, 0);
as stated in the code. How can I understand which line of code or
sequence causes the problem?
The line always is raise ESocketException.Create('Test exception in WSocket')
:)
---
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
Re: [twsocket] Test Exception in WSocket
Arno Garrels wrote: Fastream Technologies wrote: I randomly get the test exception fired in my code. Make sure your custom messages are in a range above WH_MAX_MSG!! I mean custom messages posted to a thread, if you post custom messages to a custom window it doesn't matter. --- 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
Re: [twsocket] Interesting multithreading issue: race conditionwhentriggering an event handler
Arno Garrels wrote: Francois PIETTE wrote: I've found an interesting multithreading issue which is related not The solution is to rewrite the procedure as follow: Line1: procedure TMyComponent.TriggerMyEvent(MyArg : Integer); Line2: var Line3: TMyEventProc EventProc; Line4: begin Line5: EventProc := OnMyEvent; Line6: if Assigned(EventProc) then Line7: EventProc(Self, MyArg); Line8: end; Saving the event pointer in line5 make sure that it is still valid in the case a thread switch between Line 6 and 7 occur and the OnMyEvent is set to nil by the other thread. Interesting, isn't it ? I think it's better/faster than having critical sections for all triggers, do you plan to change all ICS triggers accordingly? This requires atomic reading/writing of a Pointer (no thread switch while read/write), I'm not sure whether this is true. Byte variables are written/read in one go, there's no ploblem. --- 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
Re: [twsocket] Test Exception in WSocket
Here is my settings: WH_MAX_MSG = 400 and #define WM_HTTP_CLIENT_THREAD_ATTACH (WM_APP + 444) #define WM_HTTP_CLIENT_THREAD_DETACH (WM_APP + 445) these are the two only messages. And still the same exception. I test this problem with the reverse proxy and on PHPBB index page on localhost, pressing F5 continuously on Firefox. Regards, SZ - Original Message - From: Arno Garrels [EMAIL PROTECTED] To: ICS support mailing twsocket@elists.org Sent: Monday, August 07, 2006 10:25 AM Subject: Re: [twsocket] Test Exception in WSocket : Arno Garrels wrote: : Fastream Technologies wrote: : I randomly get the test exception fired in my code. : : Make sure your custom messages are in a range above : WH_MAX_MSG!! : : I mean custom messages posted to a thread, if you post : custom messages to a custom window it doesn't matter. : : : --- : 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] Interesting multithreading issue: race conditionwhentriggering an event handler
Hello Arno, This requires atomic reading/writing of a Pointer (no thread switch while read/write), I'm not sure whether this is true. Byte variables are written/read in one go, there's no ploblem. As far as I know it is also the case with a 32 bit. So should be no problem. --- Rgds, Wilfried [TeamICS] http://www.overbyte.be/eng/overbyte/teamics.html http://www.mestdagh.biz -- 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] Interesting multithreading issue: raceconditionwhentriggering an event handler
- Original Message - From: Wilfried Mestdagh [EMAIL PROTECTED] To: ICS support mailing twsocket@elists.org Sent: Monday, August 07, 2006 10:40 AM Subject: Re: [twsocket] Interesting multithreading issue: raceconditionwhentriggering an event handler : Hello Arno, : : This requires atomic reading/writing of a Pointer (no thread switch : while read/write), I'm not sure whether this is true. Byte variables : are written/read in one go, there's no ploblem. : : As far as I know it is also the case with a 32 bit. So should be no : problem. I think it is related with what the machine word is. For Athlon 64, it is 64 bits! Regards, SZ -- 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] Interesting multithreading issue: raceconditionwhentriggering an event handler
This requires atomic reading/writing of a Pointer (no thread switch while read/write), I'm not sure whether this is true. I think so since pointer are 32 bits and are accessed by only one memory cycle. If you look at the Windows API InterlockedXYZ function, there is none to access a single 32 bit value. So I guess it is guaranteed to have a 32 bit access done in one chunk. 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: Monday, August 07, 2006 9:35 AM Subject: Re: [twsocket] Interesting multithreading issue: raceconditionwhentriggering an event handler Arno Garrels wrote: Francois PIETTE wrote: I've found an interesting multithreading issue which is related not The solution is to rewrite the procedure as follow: Line1: procedure TMyComponent.TriggerMyEvent(MyArg : Integer); Line2: var Line3: TMyEventProc EventProc; Line4: begin Line5: EventProc := OnMyEvent; Line6: if Assigned(EventProc) then Line7: EventProc(Self, MyArg); Line8: end; Saving the event pointer in line5 make sure that it is still valid in the case a thread switch between Line 6 and 7 occur and the OnMyEvent is set to nil by the other thread. Interesting, isn't it ? I think it's better/faster than having critical sections for all triggers, do you plan to change all ICS triggers accordingly? This requires atomic reading/writing of a Pointer (no thread switch while read/write), I'm not sure whether this is true. Byte variables are written/read in one go, there's no ploblem. --- 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] Test Exception in WSocket
Fastream Technologies wrote: Here is my settings: WH_MAX_MSG = 400 and #define WM_HTTP_CLIENT_THREAD_ATTACH (WM_APP + 444) #define WM_HTTP_CLIENT_THREAD_DETACH (WM_APP + 445) these are the two only messages. And still the same exception. With above messages there should be no collision, however someone must post the message number assigned to FMsg_WM_TRIGGER_EXCEPTION to either the thread where the V6 component window is attached to or to the V6 component window handle directly. --- Arno Garrels [TeamICS] http://www.overbyte.be/eng/overbyte/teamics.html Regards, SZ - Original Message - From: Arno Garrels [EMAIL PROTECTED] To: ICS support mailing twsocket@elists.org Sent: Monday, August 07, 2006 10:25 AM Subject: Re: [twsocket] Test Exception in WSocket Arno Garrels wrote: Fastream Technologies wrote: I randomly get the test exception fired in my code. Make sure your custom messages are in a range above WH_MAX_MSG!! I mean custom messages posted to a thread, if you post custom messages to a custom window it doesn't matter. --- 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] Test Exception in WSocket
I do not know of any such poster routine. What I do to reproduce the problem is to press F5 on browser which means the connection is opened but then aborted abruptly. HTH, SZ - Original Message - From: Arno Garrels [EMAIL PROTECTED] To: ICS support mailing twsocket@elists.org Sent: Monday, August 07, 2006 11:28 AM Subject: Re: [twsocket] Test Exception in WSocket : Fastream Technologies wrote: : Here is my settings: WH_MAX_MSG = 400 and : : #define WM_HTTP_CLIENT_THREAD_ATTACH (WM_APP + 444) : #define WM_HTTP_CLIENT_THREAD_DETACH (WM_APP + 445) : : these are the two only messages. And still the same exception. : : With above messages there should be no collision, however : someone must post the message number assigned to : FMsg_WM_TRIGGER_EXCEPTION to either the thread where the : V6 component window is attached to or to the V6 component : window handle directly. : : --- : Arno Garrels [TeamICS] : http://www.overbyte.be/eng/overbyte/teamics.html : : : : Regards, : : SZ : : - Original Message - : From: Arno Garrels [EMAIL PROTECTED] : To: ICS support mailing twsocket@elists.org : Sent: Monday, August 07, 2006 10:25 AM : Subject: Re: [twsocket] Test Exception in WSocket : : : Arno Garrels wrote: : Fastream Technologies wrote: : I randomly get the test exception fired in my code. : : Make sure your custom messages are in a range above : WH_MAX_MSG!! : : I mean custom messages posted to a thread, if you post : custom messages to a custom window it doesn't matter. : : : --- : 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] Interesting multithreading issue:raceconditionwhentriggering an event handler
Francois Piette wrote: This requires atomic reading/writing of a Pointer (no thread switch while read/write), I'm not sure whether this is true. I think so since pointer are 32 bits and are accessed by only one memory cycle. If you look at the Windows API InterlockedXYZ function, there is none to access a single 32 bit value. So I guess it is guaranteed to have a 32 bit access done in one chunk. In order to clear myself up finally I goggled a bit and found this: http://windowssdk.msdn.microsoft.com/en-us/library/ms684122.aspx Simple reads and writes to properly-aligned 32-bit variables are atomic. In other words, when one thread is updating a 32-bit variable, you will not end up with only one portion of the variable updated; all 32 bits are updated in an atomic fashion. However, access is not guaranteed to be synchronized. If two threads are reading and writing from the same variable, you cannot determine if one thread will perform its read operation before the other performs its write operation. Simple reads and writes to properly aligned 64-bit variables are atomic on 64-bit Windows. Reads and writes to 64-bit values are not guaranteed to be atomic on 32-bit Windows. Reads and writes to variables of other sizes are not guaranteed to be atomic on any platform. But is this also true for Unix OS? Some articles I found say that atomicity is garanteed up to native int only. --- Arno Garrels [TeamICS] http://www.overbyte.be/eng/overbyte/teamics.html 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: Monday, August 07, 2006 9:35 AM Subject: Re: [twsocket] Interesting multithreading issue: raceconditionwhentriggering an event handler Arno Garrels wrote: Francois PIETTE wrote: I've found an interesting multithreading issue which is related not The solution is to rewrite the procedure as follow: Line1: procedure TMyComponent.TriggerMyEvent(MyArg : Integer); Line2: var Line3: TMyEventProc EventProc; Line4: begin Line5: EventProc := OnMyEvent; Line6: if Assigned(EventProc) then Line7: EventProc(Self, MyArg); Line8: end; Saving the event pointer in line5 make sure that it is still valid in the case a thread switch between Line 6 and 7 occur and the OnMyEvent is set to nil by the other thread. Interesting, isn't it ? I think it's better/faster than having critical sections for all triggers, do you plan to change all ICS triggers accordingly? This requires atomic reading/writing of a Pointer (no thread switch while read/write), I'm not sure whether this is true. Byte variables are written/read in one go, there's no ploblem. --- 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] Test Exception in WSocket
You have some part of your code post a random message. I suggest you use Microsoft Spy++ tool to spy on your application messages. -- [EMAIL PROTECTED] http://www.overbyte.be - Original Message - From: Fastream Technologies [EMAIL PROTECTED] To: ICS support mailing twsocket@elists.org Sent: Monday, August 07, 2006 11:15 AM Subject: Re: [twsocket] Test Exception in WSocket I do not know of any such poster routine. What I do to reproduce the problem is to press F5 on browser which means the connection is opened but then aborted abruptly. HTH, SZ - Original Message - From: Arno Garrels [EMAIL PROTECTED] To: ICS support mailing twsocket@elists.org Sent: Monday, August 07, 2006 11:28 AM Subject: Re: [twsocket] Test Exception in WSocket : Fastream Technologies wrote: : Here is my settings: WH_MAX_MSG = 400 and : : #define WM_HTTP_CLIENT_THREAD_ATTACH (WM_APP + 444) : #define WM_HTTP_CLIENT_THREAD_DETACH (WM_APP + 445) : : these are the two only messages. And still the same exception. : : With above messages there should be no collision, however : someone must post the message number assigned to : FMsg_WM_TRIGGER_EXCEPTION to either the thread where the : V6 component window is attached to or to the V6 component : window handle directly. : : --- : Arno Garrels [TeamICS] : http://www.overbyte.be/eng/overbyte/teamics.html : : : : Regards, : : SZ : : - Original Message - : From: Arno Garrels [EMAIL PROTECTED] : To: ICS support mailing twsocket@elists.org : Sent: Monday, August 07, 2006 10:25 AM : Subject: Re: [twsocket] Test Exception in WSocket : : : Arno Garrels wrote: : Fastream Technologies wrote: : I randomly get the test exception fired in my code. : : Make sure your custom messages are in a range above : WH_MAX_MSG!! : : I mean custom messages posted to a thread, if you post : custom messages to a custom window it doesn't matter. : : : --- : 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] Interesting multithreadingissue:raceconditionwhentriggering an event handler
This raise the following question : Is a field variable in a class aligned in memory ? (OnMyEvent variable is just a field variable). -- [EMAIL PROTECTED] http://www.overbyte.be - Original Message - From: Arno Garrels [EMAIL PROTECTED] To: ICS support mailing twsocket@elists.org Sent: Monday, August 07, 2006 11:27 AM Subject: Re: [twsocket] Interesting multithreadingissue:raceconditionwhentriggering an event handler Francois Piette wrote: This requires atomic reading/writing of a Pointer (no thread switch while read/write), I'm not sure whether this is true. I think so since pointer are 32 bits and are accessed by only one memory cycle. If you look at the Windows API InterlockedXYZ function, there is none to access a single 32 bit value. So I guess it is guaranteed to have a 32 bit access done in one chunk. In order to clear myself up finally I goggled a bit and found this: http://windowssdk.msdn.microsoft.com/en-us/library/ms684122.aspx Simple reads and writes to properly-aligned 32-bit variables are atomic. In other words, when one thread is updating a 32-bit variable, you will not end up with only one portion of the variable updated; all 32 bits are updated in an atomic fashion. However, access is not guaranteed to be synchronized. If two threads are reading and writing from the same variable, you cannot determine if one thread will perform its read operation before the other performs its write operation. Simple reads and writes to properly aligned 64-bit variables are atomic on 64-bit Windows. Reads and writes to 64-bit values are not guaranteed to be atomic on 32-bit Windows. Reads and writes to variables of other sizes are not guaranteed to be atomic on any platform. But is this also true for Unix OS? Some articles I found say that atomicity is garanteed up to native int only. --- Arno Garrels [TeamICS] http://www.overbyte.be/eng/overbyte/teamics.html 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: Monday, August 07, 2006 9:35 AM Subject: Re: [twsocket] Interesting multithreading issue: raceconditionwhentriggering an event handler Arno Garrels wrote: Francois PIETTE wrote: I've found an interesting multithreading issue which is related not The solution is to rewrite the procedure as follow: Line1: procedure TMyComponent.TriggerMyEvent(MyArg : Integer); Line2: var Line3: TMyEventProc EventProc; Line4: begin Line5: EventProc := OnMyEvent; Line6: if Assigned(EventProc) then Line7: EventProc(Self, MyArg); Line8: end; Saving the event pointer in line5 make sure that it is still valid in the case a thread switch between Line 6 and 7 occur and the OnMyEvent is set to nil by the other thread. Interesting, isn't it ? I think it's better/faster than having critical sections for all triggers, do you plan to change all ICS triggers accordingly? This requires atomic reading/writing of a Pointer (no thread switch while read/write), I'm not sure whether this is true. Byte variables are written/read in one go, there's no ploblem. --- 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] Interestingmultithreadingissue:raceconditionwhentriggering an event handler
Francois Piette wrote: This raise the following question : Is a field variable in a class aligned in memory ? (OnMyEvent variable is just a field variable). I don't know, and it also raises a second question: Reads and writes to variables of other sizes are not guaranteed to be atomic on any platform. Are i.e. reads/writes of Byte-variables not atomic in any Windows version, and if yes what versions are they? If that was true for 32-Bit Win I would have to change plenty of code :( --- 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: Monday, August 07, 2006 11:27 AM Subject: Re: [twsocket] Interesting multithreadingissue:raceconditionwhentriggering an event handler Francois Piette wrote: This requires atomic reading/writing of a Pointer (no thread switch while read/write), I'm not sure whether this is true. I think so since pointer are 32 bits and are accessed by only one memory cycle. If you look at the Windows API InterlockedXYZ function, there is none to access a single 32 bit value. So I guess it is guaranteed to have a 32 bit access done in one chunk. In order to clear myself up finally I goggled a bit and found this: http://windowssdk.msdn.microsoft.com/en-us/library/ms684122.aspx Simple reads and writes to properly-aligned 32-bit variables are atomic. In other words, when one thread is updating a 32-bit variable, you will not end up with only one portion of the variable updated; all 32 bits are updated in an atomic fashion. However, access is not guaranteed to be synchronized. If two threads are reading and writing from the same variable, you cannot determine if one thread will perform its read operation before the other performs its write operation. Simple reads and writes to properly aligned 64-bit variables are atomic on 64-bit Windows. Reads and writes to 64-bit values are not guaranteed to be atomic on 32-bit Windows. Reads and writes to variables of other sizes are not guaranteed to be atomic on any platform. But is this also true for Unix OS? Some articles I found say that atomicity is garanteed up to native int only. --- Arno Garrels [TeamICS] http://www.overbyte.be/eng/overbyte/teamics.html 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: Monday, August 07, 2006 9:35 AM Subject: Re: [twsocket] Interesting multithreading issue: raceconditionwhentriggering an event handler Arno Garrels wrote: Francois PIETTE wrote: I've found an interesting multithreading issue which is related not The solution is to rewrite the procedure as follow: Line1: procedure TMyComponent.TriggerMyEvent(MyArg : Integer); Line2: var Line3: TMyEventProc EventProc; Line4: begin Line5: EventProc := OnMyEvent; Line6: if Assigned(EventProc) then Line7: EventProc(Self, MyArg); Line8: end; Saving the event pointer in line5 make sure that it is still valid in the case a thread switch between Line 6 and 7 occur and the OnMyEvent is set to nil by the other thread. Interesting, isn't it ? I think it's better/faster than having critical sections for all triggers, do you plan to change all ICS triggers accordingly? This requires atomic reading/writing of a Pointer (no thread switch while read/write), I'm not sure whether this is true. Byte variables are written/read in one go, there's no ploblem. --- 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] Test Exception in WSocket
Hello, AFAIK, this tool comes with VC++. Unfortunately I do not have that installed. Anyway, when you say random message, I guess you mean some code is posting with wrong message number. Hmmm, strange... Thanks, SubZero - Original Message - From: Francois Piette [EMAIL PROTECTED] To: ICS support mailing twsocket@elists.org Sent: Monday, August 07, 2006 12:52 PM Subject: Re: [twsocket] Test Exception in WSocket : You have some part of your code post a random message. : I suggest you use Microsoft Spy++ tool to spy on your application messages. : -- : [EMAIL PROTECTED] : http://www.overbyte.be : - Original Message - : From: Fastream Technologies [EMAIL PROTECTED] : To: ICS support mailing twsocket@elists.org : Sent: Monday, August 07, 2006 11:15 AM : Subject: Re: [twsocket] Test Exception in WSocket : : : I do not know of any such poster routine. What I do to reproduce the : problem : is to press F5 on browser which means the connection is opened but then : aborted abruptly. : : HTH, : : SZ : : - Original Message - : From: Arno Garrels [EMAIL PROTECTED] : To: ICS support mailing twsocket@elists.org : Sent: Monday, August 07, 2006 11:28 AM : Subject: Re: [twsocket] Test Exception in WSocket : : : : Fastream Technologies wrote: : : Here is my settings: WH_MAX_MSG = 400 and : : : : #define WM_HTTP_CLIENT_THREAD_ATTACH (WM_APP + 444) : : #define WM_HTTP_CLIENT_THREAD_DETACH (WM_APP + 445) : : : : these are the two only messages. And still the same exception. : : : : With above messages there should be no collision, however : : someone must post the message number assigned to : : FMsg_WM_TRIGGER_EXCEPTION to either the thread where the : : V6 component window is attached to or to the V6 component : : window handle directly. : : : : --- : : Arno Garrels [TeamICS] : : http://www.overbyte.be/eng/overbyte/teamics.html : : : : : : : : Regards, : : : : SZ : : : : - Original Message - : : From: Arno Garrels [EMAIL PROTECTED] : : To: ICS support mailing twsocket@elists.org : : Sent: Monday, August 07, 2006 10:25 AM : : Subject: Re: [twsocket] Test Exception in WSocket : : : : : : Arno Garrels wrote: : : Fastream Technologies wrote: : : I randomly get the test exception fired in my code. : : : : Make sure your custom messages are in a range above : : WH_MAX_MSG!! : : : : I mean custom messages posted to a thread, if you post : : custom messages to a custom window it doesn't matter. : : : : : : --- : : 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 -- 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] Interesting multithreading issue: race condition when triggering an event handler
This raise the following question : Is a field variable in a class aligned in memory ? (OnMyEvent variable is just a field variable). I don't know, and it also raises a second question: Reads and writes to variables of other sizes are not guaranteed to be atomic on any platform. Are i.e. reads/writes of Byte-variables not atomic in any Windows version, and if yes what versions are they? If that was true for 32-Bit Win I would have to change plenty of code :( Anything shorter than a 32 bit integer and properly aligned is always atomic. As a byt can't be split, it is always read/written atomicly. -- [EMAIL PROTECTED] Author of ICS (Internet Component Suite, freeware) Author of MidWare (Multi-tier framework, freeware) 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] Interestingmultithreadingissue:raceconditionwhentriggering an event handler
Francois Piette wrote:
This raise the following question : Is a field variable in a class
aligned in memory ? (OnMyEvent variable is just a field variable).
Isn't a field properly aligned in memory when switch {$A8} is set?
---
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: Monday, August 07, 2006 11:27 AM
Subject: Re: [twsocket] Interesting
multithreadingissue:raceconditionwhentriggering an event handler
Francois Piette wrote:
This requires atomic reading/writing of a Pointer (no thread switch
while read/write), I'm not sure whether this is true.
I think so since pointer are 32 bits and are accessed by only one
memory cycle. If you look at the Windows API InterlockedXYZ
function, there is none to access a single 32 bit value. So I guess
it is guaranteed to have a 32 bit access done in one chunk.
In order to clear myself up finally I goggled a bit and found this:
http://windowssdk.msdn.microsoft.com/en-us/library/ms684122.aspx
Simple reads and writes to properly-aligned 32-bit variables are
atomic.
In other words, when one thread is updating a 32-bit variable, you
will not end up with only one portion of the variable updated; all 32
bits are updated in an atomic fashion. However, access is not
guaranteed to be synchronized. If two threads are reading and writing
from the same variable, you cannot determine if one thread will
perform its read operation before the other performs its write
operation.
Simple reads and writes to properly aligned 64-bit variables are
atomic on
64-bit Windows. Reads and writes to 64-bit values are not guaranteed
to be atomic on 32-bit Windows. Reads and writes to variables of
other sizes are not guaranteed to be atomic on any platform.
But is this also true for Unix OS? Some articles I found say that
atomicity is garanteed up to native int only.
---
Arno Garrels [TeamICS]
http://www.overbyte.be/eng/overbyte/teamics.html
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: Monday, August 07, 2006 9:35 AM
Subject: Re: [twsocket] Interesting multithreading issue:
raceconditionwhentriggering an event handler
Arno Garrels wrote:
Francois PIETTE wrote:
I've found an interesting multithreading issue which is related
not The solution is to rewrite the procedure as follow:
Line1: procedure TMyComponent.TriggerMyEvent(MyArg : Integer);
Line2: var
Line3: TMyEventProc EventProc;
Line4: begin
Line5: EventProc := OnMyEvent;
Line6: if Assigned(EventProc) then
Line7: EventProc(Self, MyArg);
Line8: end;
Saving the event pointer in line5 make sure that it is still
valid in the case a thread switch between Line 6 and 7 occur and
the OnMyEvent is set to nil by the other thread.
Interesting, isn't it ?
I think it's better/faster than having critical sections for all
triggers, do you plan to change all ICS triggers accordingly?
This requires atomic reading/writing of a Pointer (no thread switch
while read/write), I'm not sure whether this is true. Byte
variables are written/read in one go, there's no ploblem.
---
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] Interestingmultithreadingissue:raceconditionwhentriggering anevent handler
Isn't a field properly aligned in memory when switch {$A8} is set?
That's what the online help let me think.
Conclusion:
In addition to the code I published, one need to use {$A8} directive (Or the
equivalent project option, which is set to 8 by default) for all classes
having their event handler modified by a thread which is not the thread
triggering the event.
For completness, here is the code:
Line1: procedure TMyComponent.TriggerMyEvent(MyArg : Integer);
Line2: var
Line3: TMyEventProc EventProc;
Line4: begin
Line5: EventProc := OnMyEvent;
Line6: if Assigned(EventProc) then
Line7: EventProc(Self, MyArg);
Line8: end;
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: Monday, August 07, 2006 1:42 PM
Subject: Re:
[twsocket]Interestingmultithreadingissue:raceconditionwhentriggering anevent
handler
Francois Piette wrote:
This raise the following question : Is a field variable in a class
aligned in memory ? (OnMyEvent variable is just a field variable).
Isn't a field properly aligned in memory when switch {$A8} is set?
---
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: Monday, August 07, 2006 11:27 AM
Subject: Re: [twsocket] Interesting
multithreadingissue:raceconditionwhentriggering an event handler
Francois Piette wrote:
This requires atomic reading/writing of a Pointer (no thread switch
while read/write), I'm not sure whether this is true.
I think so since pointer are 32 bits and are accessed by only one
memory cycle. If you look at the Windows API InterlockedXYZ
function, there is none to access a single 32 bit value. So I guess
it is guaranteed to have a 32 bit access done in one chunk.
In order to clear myself up finally I goggled a bit and found this:
http://windowssdk.msdn.microsoft.com/en-us/library/ms684122.aspx
Simple reads and writes to properly-aligned 32-bit variables are
atomic.
In other words, when one thread is updating a 32-bit variable, you
will not end up with only one portion of the variable updated; all 32
bits are updated in an atomic fashion. However, access is not
guaranteed to be synchronized. If two threads are reading and writing
from the same variable, you cannot determine if one thread will
perform its read operation before the other performs its write
operation.
Simple reads and writes to properly aligned 64-bit variables are
atomic on
64-bit Windows. Reads and writes to 64-bit values are not guaranteed
to be atomic on 32-bit Windows. Reads and writes to variables of
other sizes are not guaranteed to be atomic on any platform.
But is this also true for Unix OS? Some articles I found say that
atomicity is garanteed up to native int only.
---
Arno Garrels [TeamICS]
http://www.overbyte.be/eng/overbyte/teamics.html
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: Monday, August 07, 2006 9:35 AM
Subject: Re: [twsocket] Interesting multithreading issue:
raceconditionwhentriggering an event handler
Arno Garrels wrote:
Francois PIETTE wrote:
I've found an interesting multithreading issue which is related
not The solution is to rewrite the procedure as follow:
Line1: procedure TMyComponent.TriggerMyEvent(MyArg : Integer);
Line2: var
Line3: TMyEventProc EventProc;
Line4: begin
Line5: EventProc := OnMyEvent;
Line6: if Assigned(EventProc) then
Line7: EventProc(Self, MyArg);
Line8: end;
Saving the event pointer in line5 make sure that it is still
valid in the case a thread switch between Line 6 and 7 occur and
the OnMyEvent is set to nil by the other thread.
Interesting, isn't it ?
I think it's better/faster than having critical sections for all
triggers, do you plan to change all ICS triggers accordingly?
This requires atomic reading/writing of a Pointer (no thread switch
while read/write), I'm not sure whether this is true. Byte
variables are written/read in one go, there's no ploblem.
---
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
Re: [twsocket] Test Exception in WSocket
Hello, AFAIK, this tool comes with VC++. Unfortunately I do not have that installed. I _think_ there is a freeware downloadable version. But there are also other similar tools I think. --- Rgds, Wilfried [TeamICS] http://www.overbyte.be/eng/overbyte/teamics.html http://www.mestdagh.biz -- 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
[twsocket] Multithreaded Client Application
Hello, I´m writing a multi-threaded client application I read the ICS code and there is written that to make a real multi-threaded application we should do ThreadAttach and use the messageloop procedure on the execute method of the working thread. I´m doing this, but, how do I stop this thread? How can I exit from the loop to free the thread? There is written that the message WM_QUIT should be sent, but to what handler? Thanks! Éric -- 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] Multithreaded Client Application
Hello Eric, You need a message handler for the thread with a while(GetMessage(...)). Peace be upon you, SZ - Original Message - From: Éric Fleming Bonilha [EMAIL PROTECTED] To: twsocket@elists.org Sent: Monday, August 07, 2006 4:45 PM Subject: [twsocket] Multithreaded Client Application Hello, I´m writing a multi-threaded client application I read the ICS code and there is written that to make a real multi-threaded application we should do ThreadAttach and use the messageloop procedure on the execute method of the working thread. I´m doing this, but, how do I stop this thread? How can I exit from the loop to free the thread? There is written that the message WM_QUIT should be sent, but to what handler? Thanks! Éric -- 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] Multithreaded Client Application
Hello Arno,
To make sure the events are triggered in worker thread context
you must either create the TWSocket instance from worker thread's
Execute method (suggested) or use methods ThreadDetach and
ThreadAttach.
So, in this new architecture that I´m trying to make I will create the
socket outside the thread, but than I use the ThreadAttach routine inside
the thread´s Execute method. the Execute should be something like this:
procedure TDriverCommSocketThread.Execute;
begin
if Assigned(FSocket) then
begin
//Ligar o socket ao thread
FSocket.ThreadAttach;
//Processar as mensagens
FSocket.MessageLoop;
//Desligar o socket do thread
FSocket.ThreadDetach;
end;
end;
FSocket is a pointer to socket passed to the thread´s constructor
But I think you have answered my question, so, if I use the ThreadAttach on
the Execute method and the MessageLoop on the execute, so, the
OnDataAvailable event will be triggered by the thread right? inside the
thread context. So, by doing this I could have a lenghty operation, and this
operation will not affect my main thread.
I´m thinking on one behavour:
I want to compare the behavour of 2 scenarios
First: I have a socket wich the messages are being processed by the main
thread (The default operation of ICS) and a working thread that will consume
the data received by the socket, so, the socket should receive the data and
put it on a buffer, than, the working thread periodically reads the buffer,
process the data and empty the buffer.
Second: I have a socket wich the messages are being processed by the working
thread though the socket´s MessageLoop procedure.
In both cases, what would happen if the working thread has a very very
lenghty operation (That could take a lot of seconds to complete) and the
network traffic is much intense (Like 8Mbps) ?
Correct me if I´m wrong: What would happen on first scenario is that the
main thread would be working normally receiving the network traffic and
storing it an internal buffer that I created and as the working thread is
still processing the old data, this buffer could became full in few time.
In the second, as the thread is working on the data (In the OnDataAvailable
event), it should´t process any more messages, forcing windows winsock to
notify the other side to stop sendind packets until it could process it
again.
So, I think that if it is this that happens (I don´t really know if winsock
works like this), the second scenario would be more appropriate as the
network traffic could be suspended a little while the thread is processing
the data.
I think that this may be a little confusing :)
Thanks!
Éric
- Original Message -
From: Arno Garrels [EMAIL PROTECTED]
To: ICS support mailing twsocket@elists.org
Sent: Monday, August 07, 2006 12:25 PM
Subject: Re: [twsocket] Multithreaded Client Application
Éric Fleming Bonilha wrote:
So, one doubt that I have is, if I´m using a thread to process the
socket
messages using the MessageLoop procedure, all the TWSocket events like
OnSessionConnected and OnDataAvailable is triggered using the thread
context, right? So, my handle for those events should be working on
the
thread context?
To make sure the events are triggered in worker thread context
you must either create the TWSocket instance from worker thread's
Execute method (suggested) or use methods ThreadDetach and ThreadAttach.
To realize a poll in intervals you could write a message loop in Execute
by the help of Windows function MsgWaitForMultipleObjects().
Does this answer your question, I'm not sure whether I understood it
correctly?
For instance the Excecute method may look something like below.
CurTimeOut := 1;
StartTicks := GetTickCount;
while not Terminated do
begin
Res := MsgWaitForMultipleObjects(0,
Dummy,
False,
CurTimeOut,
QS_POSTMESSAGE or QS_SENDMESSAGE);
// if there is one or more messages in the queue ...
if Res = (WAIT_OBJECT_0 + 0) then
begin
while PeekMessage(Msg, 0, 0, 0, PM_REMOVE) do
begin
case Msg.message of
WM_QUIT : begin Terminate; Break; end;
{more, user defined messages here}
[..]
else
TranslateMessage(Msg);
DispatchMessage(Msg);
end;
end;
{ Recalculate Timeout }
CurTicksAppart := CalcTicksAppart(StartTicks, GetTickCount);
if CurTicksAppart = CurTimeOut then
begin
if not Terminated then
DoSomething;
StartTicks := GetTickCount;
CurTimeOut := 1;
end
else
Dec(CurTimeout, CurTicksAppart);
end
else if Res = WAIT_TIMEOUT then
begin
if not Terminated then
DoSomething;
StartTicks :=
Re: [twsocket] Multithreaded Client Application
Éric Fleming Bonilha wrote: the Execute should be something like this: Looks OK, principally :) --- 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
Re: [twsocket] Multithreaded Client Application
Thanks a lot Arno! :) - Original Message - From: Arno Garrels [EMAIL PROTECTED] To: ICS support mailing twsocket@elists.org Sent: Monday, August 07, 2006 2:13 PM Subject: Re: [twsocket] Multithreaded Client Application Éric Fleming Bonilha wrote: the Execute should be something like this: Looks OK, principally :) --- 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] Multithreaded Client Application
Hello Éric, FSocket is a pointer to socket passed to the thread´s constructor Execute method is ok. Dont forget to ThreadDetach before giving the socket to the thread. Aslo be aware that between the Detach/Attach there is no window assigned and the socket will not be notified of data. It is only a fraction of time of course. OnDataAvailable event will be triggered by the thread right? inside the thread context. So, by doing this I could have a lenghty operation, and this operation will not affect my main thread. Correct, all events will execute in the thread context. Dont forget to set Multithreded to True, otherwise you will have a false thread because the main thraed message pump will be used. Correct me if I´m wrong: What would happen on first scenario is that the main thread would be working normally receiving the network traffic and storing it an internal buffer that I created and as the working thread is still processing the old data, this buffer could became full in few time. Yes and then the other side will wait until buffer is ready to receive again. It will be the same in both case. In the second, as the thread is working on the data (In the OnDataAvailable event), it should´t process any more messages, forcing windows winsock to notify the other side to stop sendind packets until it could process it again. Same answer. Buffer will go full and when you receive again other side start sending again. So, I think that if it is this that happens (I don´t really know if winsock works like this), the second scenario would be more appropriate as the network traffic could be suspended a little while the thread is processing the data. You can also call Suspend / Resume to control it yourself if nececary. --- Rgds, Wilfried [TeamICS] http://www.overbyte.be/eng/overbyte/teamics.html http://www.mestdagh.biz -- 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] Multithreaded Client Application
Hello Wilfried, Thank you so much, you clarified me even more :) Now I know how I need to do the job :) Thank you all Éric Fleming Bonilha - Original Message - From: Wilfried Mestdagh [EMAIL PROTECTED] To: ICS support mailing twsocket@elists.org Sent: Monday, August 07, 2006 2:37 PM Subject: Re: [twsocket] Multithreaded Client Application Hello Éric, FSocket is a pointer to socket passed to the thread´s constructor Execute method is ok. Dont forget to ThreadDetach before giving the socket to the thread. Aslo be aware that between the Detach/Attach there is no window assigned and the socket will not be notified of data. It is only a fraction of time of course. OnDataAvailable event will be triggered by the thread right? inside the thread context. So, by doing this I could have a lenghty operation, and this operation will not affect my main thread. Correct, all events will execute in the thread context. Dont forget to set Multithreded to True, otherwise you will have a false thread because the main thraed message pump will be used. Correct me if I´m wrong: What would happen on first scenario is that the main thread would be working normally receiving the network traffic and storing it an internal buffer that I created and as the working thread is still processing the old data, this buffer could became full in few time. Yes and then the other side will wait until buffer is ready to receive again. It will be the same in both case. In the second, as the thread is working on the data (In the OnDataAvailable event), it should´t process any more messages, forcing windows winsock to notify the other side to stop sendind packets until it could process it again. Same answer. Buffer will go full and when you receive again other side start sending again. So, I think that if it is this that happens (I don´t really know if winsock works like this), the second scenario would be more appropriate as the network traffic could be suspended a little while the thread is processing the data. You can also call Suspend / Resume to control it yourself if nececary. --- Rgds, Wilfried [TeamICS] http://www.overbyte.be/eng/overbyte/teamics.html http://www.mestdagh.biz -- 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
[twsocket] Design verification TCP and COM-Server
Hello, I'm currently writing a COM-Server which also uses TWSocket for some TCP connection. When the COM-Server's client calls some initializing method on my COM-Server a TCP Socket is created which listens for a incomming connection on a certain port. There should only exist one connection over this TCP socket, since the server shall only serve one client. In the OnSessionAvailable another TWSocket is created which gets passed over the connection. Is this design correct esp. for the message handling? The VCL part of the COM server isn't involved here. I also might want to send over that TCP-client socket from several threads. Is that okay? (because the COM-Server uses a Single Threaded Appartment modell) Greetings Markus -- 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] Design verification TCP and COM-Server
Your design is correct altough you'd better use TWSocketServer instead of reinventing the wheel. You can set MaxClients to one to support only one client at a time. Calling send from another thread is OK because it is protected by a critical section. Note that the prefered design is to have all communication stuff handled by a single thread and use inter-thread communication (for example Windows messages) to make a real blackbox with your communication engine. It will be much simpler to develop and debug. And you'll be forced to have a better view of what you are doing. A final note: you need to have a message pump in your thread in order to have message processing and thus events properly working. This is one more reason to have a single thread dedictaed to your communication stuff: not all COM client have a working message pump in their thread ! Contribute to the SSL Effort. Visit http://www.overbyte.be/eng/ssl.html -- [EMAIL PROTECTED] The author for the freeware multi-tier middleware MidWare The author of the freeware Internet Component Suite (ICS) http://www.overbyte.be - Original Message - From: Markus Humm [EMAIL PROTECTED] To: twsocket@elists.org Sent: Monday, August 07, 2006 7:59 PM Subject: [twsocket] Design verification TCP and COM-Server Hello, I'm currently writing a COM-Server which also uses TWSocket for some TCP connection. When the COM-Server's client calls some initializing method on my COM-Server a TCP Socket is created which listens for a incomming connection on a certain port. There should only exist one connection over this TCP socket, since the server shall only serve one client. In the OnSessionAvailable another TWSocket is created which gets passed over the connection. Is this design correct esp. for the message handling? The VCL part of the COM server isn't involved here. I also might want to send over that TCP-client socket from several threads. Is that okay? (because the COM-Server uses a Single Threaded Appartment modell) Greetings Markus -- 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
