Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
Date: Wed, 4 Sep 2002 08:34:10 +0200 (MEST)
From: Bjoern Kahl AG Resy <kahl AT informatik DOT uni-kl DOT de>
To: Corinna Vinschen <cygwin AT cygwin DOT com>
Subject: RE: A Simple Real World Benchmark for cygwin
In-Reply-To: <CHEDKHJJDLOCCOFLMGEAOEIECLAA.dvasaru@broadpark.no>
Message-ID: <Pine.GSO.4.44.0209040749130.1042-100000@domino.informatik.uni-kl.de>
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII


 Hi!

 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
     thread

 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
 CoInit
           lstat   ->   Conint
                    <thread time exeeded>
 CoUninit
                    <thread continues with new time-slice>
                    <process lstat-workload>
                        CoUninit
           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 ...


   Bjoern

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



--
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/