Mail Archives: cygwin/2002/09/03/12:05:29
Corrina,
Here's an idea that may work:
I run another quick benchmark that shows CoInit/CoUninit are "free" if
another CoInit is in effect. So we could make sure that the first CoInit is
not matched, whereas the rest are:
check_shortcut()
{
CoInit(..);
...
if (per_thread_coinit_count != 0) CoUnit(...); // always call except first
time
per_thread_coinit_count++;
}
Now, the per_thread_coinit_count variable needs to be checked somewhere to
call CoUnit once more during thread/mainthread termination.
Note that if wellbehaved application calls CoUninit, it must have called
CoInit, so the COM use count never falls to zero.
Dan.
-----Original Message-----
From: cygwin-owner AT cygwin DOT com [mailto:cygwin-owner AT cygwin DOT com]On Behalf
Of Corinna Vinschen
Sent: Tuesday, September 03, 2002 2:42 PM
To: cygwin AT cygwin DOT com
Subject: Re: A Simple Real World Benchmark for cygwin
On Tue, Sep 03, 2002 at 09:59:57PM +1000, Robert Collins wrote:
> On Tue, 2002-09-03 at 21:51, Corinna Vinschen wrote:
>
> > Yep, that's the problem. And the reasoning for calling CoInit/CoUnint
> > always as pair here since there's no way to rely on that the application
> > will *not* call CoUnit somewhere in the middle of its processing.
>
> If it does, and it didnt' call CoInit, it is an application bug, and not
> our problem. Thats why there is the requirement to pair the calls - to
> allow us to call it once when we need it, and once on shutdown. If we
> need to call it once per thread, then IMO we simply set a per-thread
> flag when we have called it.
That's not the point. The application *may* call CoInit() before
requesting the first path to a shortcut and it *may* call CoUninit()
before requesting another path to a shortcut, all in the same thread.
The CoInit/CoUnint brace in shortcut.c is safe against that:
Application Cygwin-DLL
CoInit()
lstat() -> CoInit()
CoUninit()
CoUninit()
lstat() -> CoInit()
CoUninit()
while storing our own state is not safe:
Application Cygwin-DLL
CoInit()
CoInit()
lstat() -> ok
CoUninit()
lstat() -> ???
To workaround that situation, Cygwin would have to call CoInit()
anyway to know it's state. Since that requires to be balanced
according to MSDN...
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Developer mailto:cygwin AT cygwin DOT com
Red Hat, Inc.
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
- Raw text -