RE: A Simple Real World Benchmark for cygwin

["Dan Vasaru" <dvasaru at broadpark dot no>]

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@cygwin.com [mailto:cygwin-owner@cygwin.com]On Behalf
Of Corinna Vinschen
Sent: Tuesday, September 03, 2002 2:42 PM
To: cygwin@cygwin.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@cygwin.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/