This is the mail archive of the mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: A Simple Real World Benchmark for cygwin


 I think, there is a missunderstanding on your side, Corinna
 (see below)

On Tue, Sep. 03, 2002, Corinna Vinschen wrote:
> 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:

 As I understand MSDN, the order of CoInit and CoUnint does not
 matter, as long as there is an equal number of CoUninit and CoInit
 at Process termination and the (number of CoUninit) <= (number of
 CoInit) at every other point of time.

 But then your examples are identical. I do not know details of
 the inner cygwin working, so I discuss two possible setups

 Example A)

>     Application  Cygwin-DLL
>    CoInit()
>    lstat()    ->  CoInit()
>                   CoUninit()
>    CoUninit()
>    lstat()    ->  CoInit()
>                   CoUninit()
> while storing our own state is not safe:

 Example B)
>    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...

 1.) Lets assume, application and cygwin-lstst run in the same

 In Example A), while inside the first lstat, the thread has
 two instances of COM open (from application and from cygwin),
 same in the second call to lstat.

 In Example B), inside the first lstat, it identical to example A.
 In the second lstat, there is still one COM instance open, so
 every thing is right, because all calls to CoInit and CoUninit
 are equal, only the number matters. (This follows out of the fact,
 that CoInit with S_FALSE has to be matched by a CoUninit, too.)

 2.) Assume two or more threads.
 if the application and cygwin-lstat run in different threads,
 it is even simpler:
 depending on timing, you can end up in example A) with the
 same situation as in example B) :

   application           cydwin
 Thread_1  Thread_2     Thread_X
           lstat   ->   Conint
                    <thread time exeeded>
                    <thread continues with new time-slice>
                    <process lstat-workload>
           lstat   <-  return

 You never know, where you lost CPU and when get it back.
 Note: it did not matter, if Thread_2 and Thread_X are in
 fact the same thread or two different one as shown here.

 This is pretty much the same situation as the second lstat-call
 in your example B).

 So I think, each thread that tries to do COM has to call CoInit
 exactly one time inside cygwin, remeber this fact, and call
 exactly one time CoUninit inside cygwin at thread termination.

 I hope I have not missed some thing important ...


| Dipl.-Phys. Bjoern Kahl +++ AG Embedded Systems and Robotics (RESY) |
| Informatics Faculty +++ Building 48 +++ University of Kaiserslautern|
| phone: +49-631-205-2654 +++ www:   |

Unsubscribe info:
Bug reporting:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]