From: Jeff Garzik <jeff@garzik.org>
To: Project Hail <hail-devel@vger.kernel.org>
Subject: Reconsidering libevent
Date: Tue, 21 Sep 2010 16:51:24 -0400 [thread overview]
Message-ID: <AANLkTim9Q17VvtGEUDXNiH=VyWZcdf=i+rkbF5q5qt+1@mail.gmail.com> (raw)
Today's Project Hail hacking involves moving tcp_write_* code from
itd.git to libhail. tcp_write_* is the well-debugged TCP async write
queueing code from tabled, with cosmetic changes to provide a nice API
encapsulation. I did this when moving the code originally from tabled
-> itd. By moving this code into libhail, with (yet more) cosmetic
changes, the same TCP write queueing code may be used in both tabled
and itd pkgs. chunkd'd async TCP write code is highly similar, and
can be merged into libhail as well.
(if you're curious why I'm doing this, it's one step in the road to
updating itd to use chunkd's GET_PART)
An interesting side effect: both tabled and itd use libevent, which
means that libhail must now link with libevent. Is this a bad thing?
Recently libevent was purged from cld (a simple use case, where poll
sufficed) and chunkd (obscure concerns about multi-threading), but
linking libevent into libhail is causing me to rethink the matter.
My concerns about chunkd, libevent and M-T centered around libevent's
use of a single, mutex-unprotected event_base into which events are
queued etc. In one particular thread model, the set of listened-to
events might be manipulated from multiple threads concurrently,
thereby implying a commitment to libevent implies a commitment to
libevent wrappers which add locks.
However, it turns out that thread model is quite suboptimal compared
to other methods. Assigning an incoming TCP connection to a thread,
and having that thread manage that connection for its entire lifetime,
is both much more efficient and quite compatible with libevent's API.
One merely assigns an event_base to each thread. In Apache-land, this
is called the "prefork" model (yes, I know, fork != thread; I didn't
invent the terminology)
So, I am reluctantly considering moving chunkd back to libevent. That
will enable chunkd, tabled and itd to all share the same async TCP
write code, and as a nice side effect, reduce our minor reinvention of
libevent (c.f. libtimer and some of the network poll code).
Comments welcome, as always.
Jeff
next reply other threads:[~2010-09-21 20:51 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-09-21 20:51 Jeff Garzik [this message]
2010-09-21 21:06 ` Reconsidering libevent Steven Dake
2010-09-21 21:09 ` Jeff Garzik
2010-09-21 21:41 ` Pete Zaitcev
2010-09-21 21:54 ` 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='AANLkTim9Q17VvtGEUDXNiH=VyWZcdf=i+rkbF5q5qt+1@mail.gmail.com' \
--to=jeff@garzik.org \
--cc=hail-devel@vger.kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).