[sheepdog] [PATCH 2/3] event: add deferred event register/unregister mechanism
MORITA Kazutaka
morita.kazutaka at gmail.com
Thu Jan 16 14:58:35 CET 2014
At Thu, 16 Jan 2014 16:32:42 +0800,
Liu Yuan wrote:
>
> Since current code works well, do we really need to introduce prioritized event
> loop which need some overhead of sorting events?
>
> For now with this patch set, the only benefit is that it looks more 'beautiful'
> that we have complete reg/unreg for worker threads, which isn't must for making
> code correct nor run faster.
>
> The downside is obvious, that 1) reg/unreg in worker is worsen a bit 2) event loop
> is affected negatively by sorting overhead. We don't get pratical benefits.
>
> I want to get other developer's opinion.
To be honest, I don't like both.
The current code assumes that register_event() must be called by at
most one thread. However, we don't do any check about it in
register_event(). I don't think Hitoshi's approach is a good one,
too. It adds many codes and complexity.
Do we really need exec_local_req_async() and the short event
framework? The use case of exec_local_req_async() is:
iocb = local_req_init();
loop:
...
exec_local_req_async(req, iocb);
...
ret = local_req_wait(iocb);
However, we can do the similar thing with a work queue:
wq = create_work_queue();
loop:
...
work.fn = do_work;
work.done = do_main;
queue_work(wq, &work);
...
while (nr--) {
eventfd_read(efd);
}
...
void do_work()
{
exec_local_req(req);
}
void do_main()
{
eventfd_write(efd);
}
If we can move forward without introducing an additional framework
like a short event, it looks much better way to me.
Thanks,
Kazutaka
More information about the sheepdog
mailing list