On Tue, Jan 10, 2012 at 09:10:15PM +0100, Henri Verbeet wrote:
> On 10 January 2012 20:55, Andrew Eikum wrote:
> > So it appears we should be able to launch threads in DllMain() without
> > deadlocking.
> >
> > Thoughts, anyone?
> >
> That should be easy enough to test. Is the issue just launching
On 10 January 2012 20:55, Andrew Eikum wrote:
> So it appears we should be able to launch threads in DllMain() without
> deadlocking.
>
> Thoughts, anyone?
>
That should be easy enough to test. Is the issue just launching a
thread though, or actually waiting for it to start?
On Wed, Jan 11, 2012 at 01:03:56AM +0800, Dmitry Timoshkov wrote:
> Andrew Eikum wrote:
>
> > So, I'm asking for insights. Should I try hard to avoid launching
> > threads unless absolutely necessary? Is this a known deficiency in the
> > loader, and I should do nothing? Is there some other way t
Andrew Eikum wrote:
> So, I'm asking for insights. Should I try hard to avoid launching
> threads unless absolutely necessary? Is this a known deficiency in the
> loader, and I should do nothing? Is there some other way to work
> around this?
As usually first thing to do is to write some tests a
This mail is about bugs 28042[1] and 28677[2]. In short, what I'm
trying to deal with is buggy applications that make calls to DSound
and WinMM from within DllMain(), causing deadlocks.
On almost any entry into DSound or WinMM's wave functions, the modules
launch a thread to communicate with MMDev
