From: Pete Zaitcev <zaitcev@redhat.com>
To: Jeff Garzik <jeff@garzik.org>
Cc: Project Hail List <hail-devel@vger.kernel.org>
Subject: Re: [Patch 1/1] tabled: Add replication daemon
Date: Fri, 4 Dec 2009 14:30:42 -0700 [thread overview]
Message-ID: <20091204143042.634b3ac0@redhat.com> (raw)
In-Reply-To: <4B174FD7.5090603@garzik.org>
On Thu, 03 Dec 2009 00:42:47 -0500
Jeff Garzik <jeff@garzik.org> wrote:
> On 11/26/2009 09:39 PM, Pete Zaitcev wrote:
> It seems to me you should
>
> a) leave current main-thread libevent code unchanged
>
> b) call event_base_new() for the new thread, passing that newly-created
> event_base to replica thread events using event_base_set().
Isn't it exactly what I do right now?
> event_reinit() seems more appropriate for forks than threads. tabled's
> needs are simple -- you simply need to create an additional event_base
> for the new thread.
It wasn't obvious from the description and anyway, what's the harm?
I thought it reopens some /dev/epoll or whatever may be necessary
in the OS.
> > + /* Statics are a silly way to pass arguments to threads, but oh well. */
> > + evbase = ev_base;
> > +
> > + scan_thread = g_thread_create(rep_thread_func, NULL, FALSE, &error);
>
> The second argument to g_thread_create() is a user-provided data
> pointer, passed directly to the newly created thread. No need for a
> static, AFAICS.
Ignoring the comment for now, the problem is that evbase is needed
in the "system context" of a thread, for things like passing it
down to stor_open(). That's the main reason why it's static.
Threads in Glib have something called "static private", which
kinda-sorta works like what we need, but it's a pain.
I guess I can try to use it...
-- Pete
next prev parent reply other threads:[~2009-12-04 21:30 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-11-27 2:39 [Patch 1/1] tabled: Add replication daemon Pete Zaitcev
2009-11-28 5:18 ` Jeff Garzik
2009-12-03 5:42 ` Jeff Garzik
2009-12-04 21:30 ` Pete Zaitcev [this message]
2009-12-16 0:14 ` Jeff Garzik
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20091204143042.634b3ac0@redhat.com \
--to=zaitcev@redhat.com \
--cc=hail-devel@vger.kernel.org \
--cc=jeff@garzik.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.