|
|
|
date: Fri, 14 Dec 2007 09:42:50 -0800 (PST),
group: microsoft.public.inetsdk.programming.urlmonikers
back
Re: IInternetProtocol leaking instances
StijnSanders wrote:
> I've tried MemCheck
> (http://v.mahon.free.fr/pro/freeware/memcheck/) with my own
> IInternetProtocol implementation, and it works! Funny enough, I get a
> "IEXPLORE_MemCheck.log" file in the iexplore.exe folder, but that's
> OK.
>
> What I've noticed is that I've got a number of stray instances of my
> object that implements IInternetProtocol. Is iexplore.exe not
> releasing them well? Or am I doing something wrong?
The latter is more likely. I've implemented APPs, and mine get released
just fine.
> It looks like I have as much stray instances as Start calls, should I
> do "Self.Free" on Terminate?
No. You should do this when your reference count goes down to zero.
--
With best wishes,
Igor Tandetnik
With sufficient thrust, pigs fly just fine. However, this is not
necessarily a good idea. It is hard to be sure where they are going to
land, and it could be dangerous sitting under them as they fly
overhead. -- RFC 1925
date: Fri, 14 Dec 2007 12:52:39 -0500
author: Igor Tandetnik
Re: IInternetProtocol leaking instances
More from me. I've been debugging like I've never debugged before.
And I still don't get any Release calls on instances that Start was
called on (instances used for QueryInfo get released nicely).
I've implemented a thread-pool to re-use worker threads, which is
nice, except perhaps when some 'pages' doesn't respond well to Abort
calls (I was looking how to raise an exception 'into a thread', but
haven't found it yet).
I also made a 'cleaner queue' on which I put instances of my
IInternetProtocol implementation, to clean on the next Start that
comes in. That plugs the hole for now, except perhaps for the few
instances that are left on process exit.
*Sigh*
I'll check my AddRef/Release calls once more, have a go with a new
'sandbox' IInternetProtocol implementation to compare what happens,
but if I don't find it by then, I'm about to implement a local HTTP
TCP/IP server, sadly enough.
date: Tue, 15 Jan 2008 15:49:29 -0800 (PST)
author: StijnSanders
Re: IInternetProtocol leaking instances
StijnSanders wrote:
> More from me. I've been debugging like I've never debugged before.
> And I still don't get any Release calls on instances that Start was
> called on (instances used for QueryInfo get released nicely).
Perhaps you have a circular reference. You should release any references
you have on the sink (IInternetProtocolSink you likely cached in Start,
and any pointers you've obtained with IServiceProvider::QueryService) as
soon as you no longer need them (don't have anything more to report).
Usually, this happens right after you call
IInternetProtocolSink::ReportResult (this should be the last call you
ever make on the client).
> I've implemented a thread-pool to re-use worker threads, which is
> nice, except perhaps when some 'pages' doesn't respond well to Abort
> calls (I was looking how to raise an exception 'into a thread', but
> haven't found it yet).
I don't understand what you are talking about here, sorry.
--
With best wishes,
Igor Tandetnik
With sufficient thrust, pigs fly just fine. However, this is not
necessarily a good idea. It is hard to be sure where they are going to
land, and it could be dangerous sitting under them as they fly
overhead. -- RFC 1925
date: Tue, 15 Jan 2008 19:08:56 -0500
author: Igor Tandetnik
Re: IInternetProtocol leaking instances
On 16 jan, 01:08, "Igor Tandetnik" wrote:
...
> and any pointers you've obtained with IServiceProvider::QueryService)
hmm, I'll try with an extra 'release' on the interface I get with
QueryService(IID_IHttpNegotiate...
About the 'worker thread pool': I keep about 20 threads open (or more
on a heavy-duty server), and have Start pick one of the 'free' threads
to do the work, or queue the request until one of the threads has done
with another request. Works great until the browser calls Abort, I
found out you can return 'pending' on Abort also, which solved that
problem.
In the mean time, I've dug deeper and deeper, and I discovered that
the thread IInternetProtol calls are made in isn't CoInitialized, but
still does all the RefCount and ObjectFactory magic that happens when
you create COM objects. So I checked the refcounts on my own objects
also...
I'm still getting errors, but I just found out Borland Delphi had some
issues with 'unique AnsiStrings' not being thread-safe... Which is bad
news... But moves the focus of the search to another level
altogether...
date: Mon, 3 Mar 2008 06:45:09 -0800 (PST)
author: StijnSanders
|
|
