qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 0/5] Spread the use of QEMU threading & locking


From: Jan Kiszka
Subject: Re: [Qemu-devel] [PATCH 0/5] Spread the use of QEMU threading & locking API
Date: Wed, 04 Apr 2012 19:19:52 +0200
User-agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv:1.8.1.12) Gecko/20080226 SUSE/2.0.0.12-1.1 Thunderbird/2.0.0.12 Mnenhy/0.7.5.666

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 an EventNotifier.
>>> 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 poll synchronization primitives so

Ah, you meant on Win32 you cannot poll!

>> EventNotifier has to remain separate from qemu-thread.
> 
> QemuEvent will be pollable as you can ask it for its read fd:
> 
> void qemu_event_init(QemuEvent *event, bool signaled);
> void qemu_event_destroy(QemuEvent *event);
> int qemu_event_get_write_fd(QemuEvent *event);
> int qemu_event_get_read_fd(QemuEvent *event);
> void qemu_event_signal(QemuEvent *event);
> bool qemu_event_check(QemuEvent *event);
> 
> I'm not yet convinced a qemu_event_set_handler buys us a lot, so I
> prefer the get_read_fd interface for now.

I'm starting to understand your abstraction here - makes sense. :)

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux



reply via email to

[Prev in Thread] Current Thread [Next in Thread]