How about internally renaming mono_thread_manage and add a no-op version of
it.
It would retain compatibility with wine and would not further complicate the
shutdown sequence.
Sounds good to me.
I did some further research, and it seems this would break the
shutdown process used by
On Fri, Sep 12, 2014 at 12:47 AM, Rodrigo Kumpera kump...@gmail.com wrote:
How about internally renaming mono_thread_manage and add a no-op version of
it.
It would retain compatibility with wine and would not further complicate the
shutdown sequence.
Sounds good to me.
How about internally renaming mono_thread_manage and add a no-op version of
it.
It would retain compatibility with wine and would not further complicate
the shutdown sequence.
This assumes that there's no good use case for calling the two
independently.
--
Rodrigo
On Wed, Sep 10, 2014 at 5:58
With a recent master build of Mono, I'm getting hangs in Wine when a
.NET exe exits. I think it's related to this commit:
commit 1996d664b4be7b97921485871f756db1d58011fe
Author: Rodrigo Kumpera kump...@gmail.com
Date: Mon Aug 25 14:37:22 2014 -0400
[jit] Ensure no threads are running when
2. Should Mono be fixed to account for what I was doing? I'd prefer to
have code that is as version-independent as possible. Maybe mono could
somehow detect that mono_thread_manage was already completed by the
current thread, and do nothing in this case?
I wrote a patch using this approach:
