Newsgroups : Borland : borland.public.delphi.internet.winsock : 2008 Feb : Re: destroy Threadclass and ondisconnect event
| Subject: | Re: destroy Threadclass and ondisconnect event |
| Posted by: | "Remy Lebeau (TeamB)" (no.spam@no.spam.com) |
| Date: | Tue, 12 Feb 2008 11:05:47 |
"emre varol" <none@none.com> wrote in message
news:47b16bb3$1@newsgroups.borland.com...
> Some times only one exception occurs. This is 'test2' exception that in
> the AddToQueue function. Access violation at address 7C81A379 in
> module 'ntdll.dll'. Write of address Test2 exception is related with
> FQueue threadlist.
Then clearly your code is not protecting itself adequately enough from
concurrency issues. EVERYWHERE that two connections can access the same
resource at potentially the same time, you need to have a lock for it. Your
queuing code already does that, but you are not protecting your room array
itself.
> if KAth.AddToQueue( stream ) ----> if KAth has been free
The only way that can happen is if you did not remove the thread from the
room's list before another thread tried to send data to that thread. All
the more reason to think that you are not serializing access to your rooms
good enough to prevent invalid pointers from being passed around.
> how can we go to its function(AddToQueue) if KAth has been free
From the CPU's perspective, calling an object method is no different than
calling a standalone procedure. The memory address of the method is static.
The compiler jumps to the same place each time. The only difference is that
a method has a hidden Self parameter whereas a standalone procedure does
not. It doesn't matter what the Self pointer value actually is at the time
of the calling. The method itself can still be called regardless of whether
the object is valid or not. You won't get a crash or the like until the
Self pointer is dereferenced to access one of its data members.
> In the TMyPeerThread.Destroy method FQueue threadlist is being free.
> But this TMyPeerThread class is being removed from rooms[ no ].kritiklist
> in ServerDisconnect event.
Then your problem is somewhere else.
> if ServerDisconnect event is not called by indy
It will be.
> But in which cases Indy dont call ServerDisconnect event
The OnDisconnect event will always be called.
> And FQueue variable are being free only in TMyPeerThread.Destroy method.
> if destroy method occurs how can we call KAth.AddToQueue method?
Like I said, the only way that could happen is if you have not yet removed
the thread from the room list before AddToQueue() is called again
Gambit