Re: How do I tell an object to free up an owned object from thta object itself?
From: David Reeve (dree4456_at_bigpond.net.au)
Date: 10/01/03
- Next message: doc_asm: "MultiThread safety and VCL parent-ed object"
- Previous message: Maarten Wiltink: "Re: Convert TIFF to BMP"
- Next in thread: Bo Berglund: "Re: How do I tell an object to free up an owned object from thta object itself?"
- Reply: Bo Berglund: "Re: How do I tell an object to free up an owned object from thta object itself?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Wed, 01 Oct 2003 09:35:19 GMT
"Bo Berglund" <bo.berglund@telia.com> wrote in message
news:krdinvgvlhp8ihr58p1vrfi1fkpqv218od@4ax.com...
> On Tue, 30 Sep 2003 04:38:28 GMT, "David Reeve"
> <dree4456@bigpond.net.au> wrote:
>
[snip]
I've been trying to get a good understanding of ScktComp.pas, so have done
a few tests on what you say here. I added a copy of ScktComp to my tester
so I could step it. With all those similarly named objects, it is very easy
to end up completely fuddled :-)
> Actually, what I am doing is this:
> 0. I have a Server object that creates a TServerSocket for listening
> 1. I set it to NonBlocking (that is what I am used to)
OK... the OnClientxxxxxx events will be enabled in this mode.
> 2. In the ClientConnect event I create a handler object for processing
> 3. The handler object is owned by the Server
> 4. The handler has a TCustomWinSocket variable that gets assigned
> the Socket supplied in the ClientConnect event
Fine.... the object supplied in the OnClientConnect event that is called
Socket is in fact a TServerClientWinSocket which acts as a end-connection
for one client. What happens if a second client connection is made before
the first is disconnected? I assume you instantiate a new handler object and
associate the new 'Socket' object with that. So I guess you are managing a
list of handler objects at the TServerLevel?
> 5. All client processing hencefort is done by the handler
> 6. Then the client disconnects and I can free internal handler objects
There is a possible catch here. The TServerClientWinSocket associated with
the client-connection is freed asynchronously by posting a message to itself
*after* your OnClientDisconnect handler has run. (All TServerClientWinSocket
instances are provided with a window and message handling courtesy of the
TCustomWinSocket ancestor, and respond to messages arrising from the sockets
API).
> 7. But in order not to fill up memory I also need to dispose of two
> more items:
Two more items? Aren't these freed at point 6?
> -The handler itself (which I created in the ClientConnect event)
This is simply a matter of looking through your list of handlers, and
removing, and freeing the handler associated with the 'Socket' object passed
in the OnDisconnect event.
> -The Socket that was supplied in the ClientConnect event.
This done for you asynchronously after the OnDisconnect code has run..... as
discussed above.
> Apparently the TServerSocket does not know of some client disconnects
> and thus the socket lingers on. For example if the client program is
> shut down unexpectedly then the TServerSocket still lists the socket
> as active. I don't think that the socket is ever destroyed unless I
> can initiate some cleanup action.
I can't fault TServer socket in my test. I have verified that multiple
connections add to the connection list, and are removed as expected,
regardless of whether you call close on the clients, or pre-emptively close
them. However, this simple test may not cover all eventualities. Memproof
confirms that cleanup proceeds as expected.
>
> My program will be running as an NT service in the end and thus it
> will be active a long time with many clients connecting/disconnecting
> over time.
> I don't want memory or socket usage to accumulate over time....
>
I can certainly see the possibility for a problem, and you would need to
know the failure rate if you intended to run the service over a long period
of time. However, I would work toward getting a low disconnect failure rate
before implementing a more 'belt&braces' approach of forcing a time-to-live
on every client-connection.
Dave
- Next message: doc_asm: "MultiThread safety and VCL parent-ed object"
- Previous message: Maarten Wiltink: "Re: Convert TIFF to BMP"
- Next in thread: Bo Berglund: "Re: How do I tell an object to free up an owned object from thta object itself?"
- Reply: Bo Berglund: "Re: How do I tell an object to free up an owned object from thta object itself?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
