On 24 June 2015 at 10:09, Fabien Chouteau wrote:
> If we completely change the thread synchronization on Windows, maybe
> SuspendeThread is not needed anymore, but with the current scheme (at
> least what I know of it), I don't see how we can remove it.
>
> As I said before we must be very careful
On 06/23/2015 07:07 PM, Stefan Weil wrote:
> Am 23.06.2015 um 12:46 schrieb Paolo Bonzini:
>> On 23/06/2015 12:30, Peter Maydell wrote:
>>> On 23 June 2015 at 10:55, Ян Завадовский wrote:
On Tue, Jun 23, 2015 at 9:02 AM, Stefan Weil wrote:
> We should add an URL to reliable documentation
Am 23.06.2015 um 12:46 schrieb Paolo Bonzini:
On 23/06/2015 12:30, Peter Maydell wrote:
On 23 June 2015 at 10:55, Ян Завадовский wrote:
On Tue, Jun 23, 2015 at 9:02 AM, Stefan Weil wrote:
We should add an URL to reliable documentation which supports that
claim.
Unfortunately, MSDN says only
On 23/06/2015 13:43, Daniel P. Berrange wrote:
> > We can and should just reuse glib these days as much as we can (probably
> > not entirely because glib doesn't have detached threads). At least a
> > few years ago, winpthreads was much slower than native Win32, which is
> > why everyone reinven
On Tue, Jun 23, 2015 at 01:32:19PM +0200, Paolo Bonzini wrote:
>
>
> On 23/06/2015 13:18, Daniel P. Berrange wrote:
> > > For 2.5, however, I wonder if SuspendThread/ResumeThread is needed at
> > > all now that cpu_exit doesn't have to undo block chaining anymore. Even
> > > on POSIX platforms t
On 23/06/2015 13:18, Daniel P. Berrange wrote:
> > For 2.5, however, I wonder if SuspendThread/ResumeThread is needed at
> > all now that cpu_exit doesn't have to undo block chaining anymore. Even
> > on POSIX platforms the signal might not be necessary anymore.
>
> If you don't have that signa
On 23 June 2015 at 11:46, Paolo Bonzini wrote:
> SuspendThread was pretty much the only way to emulate signals.
> Initially I used SetThreadContext to redirect execution to cpu_signal;
> that was more complicated, but in retrospect it would have avoided the
> problems with memory barriers and with
On Tue, Jun 23, 2015 at 12:46:59PM +0200, Paolo Bonzini wrote:
>
>
> On 23/06/2015 12:30, Peter Maydell wrote:
> > On 23 June 2015 at 10:55, Ян Завадовский wrote:
> >> On Tue, Jun 23, 2015 at 9:02 AM, Stefan Weil wrote:
> >>> We should add an URL to reliable documentation which supports that
>
On 23/06/2015 12:30, Peter Maydell wrote:
> On 23 June 2015 at 10:55, Ян Завадовский wrote:
>> On Tue, Jun 23, 2015 at 9:02 AM, Stefan Weil wrote:
>>> We should add an URL to reliable documentation which supports that
>>> claim.
>>
>> Unfortunately, MSDN says only "SuspendThread suspends the th
On 23 June 2015 at 10:55, Ян Завадовский wrote:
> On Tue, Jun 23, 2015 at 9:02 AM, Stefan Weil wrote:
>> We should add an URL to reliable documentation which supports that
>> claim.
>
> Unfortunately, MSDN says only "SuspendThread suspends the thread. It's
> designed for debuggers. Don't use in a
On Tue, Jun 23, 2015 at 12:49 PM, Fabien Chouteau
wrote:
>
> Maybe we can, but the "while" will only loop when threads are running on
> different CPU, so the other thread is already running and calling sleep
> will not help I think.
>
What you think about this:
diff --git a/cpus.c b/cpus.c
index 8
Hello.
On Tue, Jun 23, 2015 at 9:02 AM, Stefan Weil wrote:
> Am 22.06.2015 um 23:54 schrieb Zavadovsky Yan:
>
>> Calling SuspendThread() is not enough to suspend Win32 thread.
>> We need to call GetThreadContext() after SuspendThread()
>> to make sure that OS have really suspended target thread.
On 06/23/2015 08:02 AM, Stefan Weil wrote:
> Am 22.06.2015 um 23:54 schrieb Zavadovsky Yan:
>> Calling SuspendThread() is not enough to suspend Win32 thread.
>> We need to call GetThreadContext() after SuspendThread()
>> to make sure that OS have really suspended target thread.
>> But GetThreadCont
Am 22.06.2015 um 23:54 schrieb Zavadovsky Yan:
Calling SuspendThread() is not enough to suspend Win32 thread.
We need to call GetThreadContext() after SuspendThread()
to make sure that OS have really suspended target thread.
But GetThreadContext() needs for THREAD_GET_CONTEXT
access right on thre
Calling SuspendThread() is not enough to suspend Win32 thread.
We need to call GetThreadContext() after SuspendThread()
to make sure that OS have really suspended target thread.
But GetThreadContext() needs for THREAD_GET_CONTEXT
access right on thread object.
This patch adds THREAD_GET_CONTEXT to
15 matches
Mail list logo
