This is the mail archive of the cygwin-apps 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: [PATCH/CFT] Fix setup.exe COM initialisation problem.


Dave Korn wrote:

>   I don't think the choice of threading model
> matters much to setup.exe; we only use COM for shell functions and common
> control dialogs, none of which we're doing in a parallelized or multi-threaded
> fashion, so the serialisation between threads within setup.exe implied by
> sending requests through an apartment shouldn't cause any noticeable slow
> down; this stuff is all happening in a user-interaction-driven fashion anyway.

  I've read a bit more about COM threading.  In mklink2.cc, it says:

> /* Initialized in WinMain.  This is required under Windows 7.  If 
>    CoCreateInstance gets called from here, it fails to create the
>    instance with an undocumented error code 0x80110474.
>    FIXME: I have no idea why this happens. */

  Well, I have a theory.  Moving the CoCreate call into WinMain guarantees it
is being called by the same thread that called CoInitEx, and therefore has an
apartment allocated to it - whether single or multi isn't the point here.

  Now, when the CoCreate call was in make_link_2, it would be called from
whoever called DesktopSetupPage::OnFinish().

  That ought to be the main message loop, which ought to be the main thread,
which ought to be the same thread that called CoInitEx.  But if it was a
different thread, that had never called CoInitEx, the CoCreate call would fail.

  Is it possible that in win7 the message pump has been moved out of the main
thread, perhaps to try and solve or reduce the amount of desktop lockups and
thread deadlocks?

    cheers,
      DaveK


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