Il 05/04/2012 15:00, Jan Kiszka ha scritto:
>> > But QemuEvent takes away the best name for a useful concept (a
>> > cross-platform implementation of Win32 events; you can see that in the
> The concept is not lost, it perfectly fit this incarnation. Just the
> special futex version for Linux is not
On 2012-04-05 14:48, Paolo Bonzini wrote:
> Il 05/04/2012 14:04, Jan Kiszka ha scritto:
>>> EventNotifier _is not_ yet another thread synchronization primitive. It
>>> can be used across processes, across the user/kernel boundary, and the
>>> main loop can wait on multiple instances. QemuThread s
On 2012-04-05 09:51, Paolo Bonzini wrote:
> Il 04/04/2012 19:19, Jan Kiszka ha scritto:
Yep, this screams for something like QemuEvent which pleases all users
of current qemu_eventfd and EventNotifier - and fit into the existing
threading/synchronization abstraction layou
Il 05/04/2012 16:01, Jan Kiszka ha scritto:
> Either you signal via the fd or via a variable. Doing both won't work as
> the state can only be in the eventfd/pipe (for external triggers). We
> could switch the mode of our QemuEvent on init, but that will become
> ugly I'm afraid.
Yeah...
> RC
On 2012-04-05 15:40, Paolo Bonzini wrote:
> Il 05/04/2012 15:00, Jan Kiszka ha scritto:
But QemuEvent takes away the best name for a useful concept (a
cross-platform implementation of Win32 events; you can see that in the
>> The concept is not lost, it perfectly fit this incarnation. Just
Il 05/04/2012 14:04, Jan Kiszka ha scritto:
>> EventNotifier _is not_ yet another thread synchronization primitive. It
>> can be used across processes, across the user/kernel boundary, and the
>> main loop can wait on multiple instances. QemuThread synchronization
>> primitives are only usable wi
On 2012-04-05 13:29, Paolo Bonzini wrote:
> Il 05/04/2012 13:18, Jan Kiszka ha scritto:
Note that the thing above would be separate from EventNotifier, which is
why I only mentioned as "by the way".
EventNotifier and anything using eventfd/pipes would _not_ be a
"QEMU-style
Il 05/04/2012 13:18, Jan Kiszka ha scritto:
>> > Note that the thing above would be separate from EventNotifier, which is
>> > why I only mentioned as "by the way".
>> >
>> > EventNotifier and anything using eventfd/pipes would _not_ be a
>> > "QEMU-styled thread synchronization mechanism" simply
On 2012-04-05 13:07, Paolo Bonzini wrote:
> Il 05/04/2012 12:55, Jan Kiszka ha scritto:
>>> BTW you _could_ have a QemuEvent primitive based on Windows manual-reset
>>> events. It can be used in some cases as a replacement for condvars,
>>> especially when you have multiple producers and a single c
Il 05/04/2012 12:55, Jan Kiszka ha scritto:
>> BTW you _could_ have a QemuEvent primitive based on Windows manual-reset
>> events. It can be used in some cases as a replacement for condvars,
>> especially when you have multiple producers and a single consumer (MPSC
>> queue is perhaps the easiest l
Il 04/04/2012 19:19, Jan Kiszka ha scritto:
>>> Yep, this screams for something like QemuEvent which pleases all users
>>> of current qemu_eventfd and EventNotifier - and fit into the existing
>>> threading/synchronization abstraction layout.
>>> >>
>>> >> Kind of, on Unix you cannot
On 2012-04-04 17:38, Jan Kiszka wrote:
> On 2012-04-04 17:29, Paolo Bonzini wrote:
>> Il 04/04/2012 17:24, Jan Kiszka ha scritto:
> For patches 3 and 4, I'd rather use an EventNotifier...
>>> ...which still lacks support for non-eventfd systems. Hmm, I guess it's
>>> time to consolidate both.
>
Il 04/04/2012 17:24, Jan Kiszka ha scritto:
>> > For patches 3 and 4, I'd rather use an EventNotifier...
> ...which still lacks support for non-eventfd systems. Hmm, I guess it's
> time to consolidate both.
Perhaps you can take the relevant patches out of the thread-blocks
branch at git://github.c
On 2012-04-04 17:29, Paolo Bonzini wrote:
> Il 04/04/2012 17:24, Jan Kiszka ha scritto:
For patches 3 and 4, I'd rather use an EventNotifier...
>> ...which still lacks support for non-eventfd systems. Hmm, I guess it's
>> time to consolidate both.
>
> Perhaps you can take the relevant patches
On 2012-04-04 18:55, Jan Kiszka wrote:
> On 2012-04-04 18:39, Paolo Bonzini wrote:
>> Il 04/04/2012 18:05, Jan Kiszka ha scritto:
> Perhaps you can take the relevant patches out of the thread-blocks
> branch at git://github.com/pbonzini/qemu.git? The iothread eventfd
> could also use a
Refreshed versions of some cleanups I already sent last year. See
patches for details.
The series also helps using different scheduling policies for QEMU
threads which includes hardening internal locks.
Jan Kiszka (5):
Introduce qemu_cond_timedwait for POSIX
Switch POSIX compat AIO to QEMU ab
On 2012-04-04 18:39, Paolo Bonzini wrote:
> Il 04/04/2012 18:05, Jan Kiszka ha scritto:
Perhaps you can take the relevant patches out of the thread-blocks
branch at git://github.com/pbonzini/qemu.git? The iothread eventfd
could also use an EventNotifier.
>> Yep, this screams for som
Il 04/04/2012 18:05, Jan Kiszka ha scritto:
>> > Perhaps you can take the relevant patches out of the thread-blocks
>> > branch at git://github.com/pbonzini/qemu.git? The iothread eventfd
>> > could also use an EventNotifier.
> Yep, this screams for something like QemuEvent which pleases all users
On 2012-04-04 17:29, Paolo Bonzini wrote:
> Il 04/04/2012 17:24, Jan Kiszka ha scritto:
For patches 3 and 4, I'd rather use an EventNotifier...
>> ...which still lacks support for non-eventfd systems. Hmm, I guess it's
>> time to consolidate both.
>
> Perhaps you can take the relevant patches
On 2012-04-04 17:18, Paolo Bonzini wrote:
> Il 04/04/2012 17:08, Jan Kiszka ha scritto:
>> Refreshed versions of some cleanups I already sent last year. See
>> patches for details.
>
> Patches 1, 2 and 5 are fine. I had an alternative implementation using
> a counting semaphore instead of the con
Il 04/04/2012 17:08, Jan Kiszka ha scritto:
> Refreshed versions of some cleanups I already sent last year. See
> patches for details.
Patches 1, 2 and 5 are fine. I had an alternative implementation using
a counting semaphore instead of the condition variable (which would work
on Windows too), b
21 matches
Mail list logo
