Thanks for your suggestion.
>
> Is there any particular reason why you are using TIdTCPServer and
> TIdTCPClient directly for that instead of TIdMappedPortTCP? It does all
> of
> the forwarding work back and forth for you automatically.
>
I didn't know this component and seems to me it's doing what I want (my
knowledge of Indy is still quite basic). I'll try to rewrite the program
using this component.
>
> All I can tell you right now is that your code is not thread-safe, not
> even
> close. You need to serious re-write your code to be safer to multiple
> threads, or else unforseen things can happen.
As I've noticed and experienced. I used a critical section to prevent
simultaneous access to the logfile, is there any reason to use
TIdThreadSafe?
For example:
>
> interface
>
> uses Forms, IdTCPClient, IdTCPServer, IdThreadMgrPool;
>
> type
> TMyNNTPThread = class(TIdPeerThread)
> private
> fClient: TIdTCPClient;
> public
> constructor Create(ACreateSuspended: boolean True); override;
> destructor Destroy; override;
> procedure Connect(const AHost: String; APort: Integer);
> property OutboundClient: TIdTCPClient read fClient;
> end;
>
I stored the different TIdPeerThread connections in a TObjectList. You
decided to create a descendant class TMyNNTPThread. A better approach imo
but I thought this wasn't possible because the original object, created by
OE, is a TIdPeerThread. In other words, no memory has been allocated for the
field TMyNNTPThread.fClient, am I right (?)So commands like
TMyNNTPThread(IdTCPClient1).Connect('somehost', 12345);
can be executed safely and don't result in a access violation? Does the cast
TMyNNTPThread(IdTCPClient1) reallocate memory? How does this work?
I would appreciate if you would shed some light on this.
