Re: get next timeout from libevent

On Tue, Nov 24, 2009 at 03:31:18PM +0100, Filippo Giunchedi wrote:
 [rewrapped]
> Hi,
>
> we are trying to build a library which uses libevent but also has
> the capability to be integrated into an application's main loop.
> 
> Our solution so far includes three functions:
> - get the list of file descriptions handled by our library
>   (IOW the list of fds in libevent)
> - register a callback to be called whenever a new fd is added
> - perform a step (i.e. basically call libevent loop once)
> 
> This way the application can poll/select on our lib fds and then make a step
> whenever necessary.
>
> So far so good (please correct me if there's something missing :)).

Hm.  I'm not sure this is such a great design.  If the application is
*already* calling poll()/select() for you, then it's redundant to have
Libevent do it as well.  Worse, if the application is actually using
poll or select, then you'll lose all the performance benefits that
you'd get from Libevent's use of fast backends like kqueue, epoll, or
evport.

Also, how are you getting "the list of fds in Libevent"?  FWICT, there
isn't a public interface that exposes that.

>  At this point though the application won't be able to get the
> timeout for the next event because AFAICS libevent's timeout_next()

Re: question about poll()

On Wed, Nov 25, 2009 at 02:44:37PM -0500, Patrick Galbraith wrote:
> Hi there all!
> 
> I'm working on trying to port libmemcached to Windows. It is not an easy 
> task! I've just found that libmemcached uses poll() and this is a bit of 
> a road-block! What do you guys do to get cross-platform support? How do 
> you transparently use poll() or other mechanisms to provide the 
> functionality that is required depending on platform?

I'm not sure what exactly you're asking; I'll answer two possible
variants of your question.  If you meant something else, my apologies.

If you mean, "how do Libevent users transparently use poll() or other
mechanisms?" then the answer is "by using Libevent": Libevent knows
about lots of different platform-specific poll()-like things, and
tries to use whichever is fastest among the available options.  You
can probably find examples of how to use Libevent by looking in the
regular memcached source.

If you mean, "how do Libevent users transparently use poll() or other
mechanisms?" then the answer is, "by having a separate implementation
for each backend mechanism, compiling as many as will compile on a
given platform, and selecting whichever one of the compiled ones works
best at runtime."  The responsibility of each backend is basically:
    - Know how to start caring about an fd for reading/writing
    - Know how to stop caring about an fd for reading/writing
    - Know how to wait up to a given number of seconds for fds to be
      ready to read/write, and
For an example of one of the simpler such backends, see select.c in
the Libevent source.  See kqueue.c or epoll.c for an example of what

Re: Threading concerns

On Mon, Nov 30, 2009 at 02:49:09AM -0500, Donghua Xu wrote:
> Thanks Nick. How do I enable the "common timeout" logic? Or is it
> enabled by default in 2.0.3-alphra?

Check out the documentation for event_base_init_common_timeout() in
include/event2/event.h in Libevent 2.0.3-alpha.

Basically, if you have many many events that all use timeouts of the
same duration, you can use the new function to make sure that they get
put in a queue rather than the minheap, so that you get O(1)
performance for adding and running each one rather than O(lg n).  If
your million timeout durations are not clustered like this, this patch
won't help.

The original patch at
https://sourceforge.net/mailarchive/message.php?msg_name=E1N7Xqx-0001rz-7M%403kljzd1.ch3.sourceforge.com
might also be good to look at.

yrs,
--

-- 
Nick
***********************************************************************
To unsubscribe, send an e-mail to majordomo <at> freehaven.net with
unsubscribe libevent-users    in the body.

Re: question about poll()

Re: get next timeout from libevent

Hi Nick,

On Tue, Dec 01, 2009 at 11:31:56PM -0500, Nick Mathewson wrote:
> > This way the application can poll/select on our lib fds and then make a
> > step whenever necessary.
> >
> > So far so good (please correct me if there's something missing :)).
> 
> Hm.  I'm not sure this is such a great design.  If the application is
> *already* calling poll()/select() for you, then it's redundant to have
> Libevent do it as well.  Worse, if the application is actually using
> poll or select, then you'll lose all the performance benefits that
> you'd get from Libevent's use of fast backends like kqueue, epoll, or
> evport.

Indeed.

> 
> Also, how are you getting "the list of fds in Libevent"?  FWICT, there
> isn't a public interface that exposes that.

Correct, there isn't, but that could be kept track of in the library itself.

> 
> >  At this point though the application won't be able to get the
> > timeout for the next event because AFAICS libevent's timeout_next()
> > isn't supposed to be called from the outside, is this correct?
> 
> Right.
> 
> I wouldn't object to adding one, if there turn out to be good uses for
> it, or as part of a general extension scheme.

This might be moot now, following your suggestions below.

> 
> >  Also, what would be the correct approach to build a library upon
> > libevent which can be then integrated into another main loop?
> 
> This are just my initial thoughts, so I don't promise they're very
> good ones:

thank you very much!
the first approach looks the most sensible for now.
Whenever the library is used in a standalone application then libevent main
loop can be used without (much?) penalty by registering callbacks in the
library which themselves register events to libevent.

the other approaches are food for thought as well!

cheers,
filippo
--

-- 
Filippo Giunchedi - http://esaurito.net - 0x6B79D401

I find television very educating. Every time somebody turns on the
set, I go into the other room and read a book.
-- Groucho Marx
***********************************************************************
To unsubscribe, send an e-mail to majordomo <at> freehaven.net with
unsubscribe libevent-users    in the body.

Re: question about poll()

NULL access on resolv_conf_parse_line

Hello,

I'm Yasuoka Masahiko of IIJ.  Nice to meet you.

Programs using evdns may crash by NULL pointer acccess on parsing a
broken resolv.conf like bellow.

  ---
  nameserver
  ---

  * On my environment, the broken resolv.conf has been created by a
    broken DHCP client.
  * A patch is attached on the end of this message.

Regards,

--yasuoka

  Yasuoka Masahiko (yasuoka <at> iij.ad.jp)
    Chief Engineer, Product Technology Section,
    Product Development Division, SEIL Business Unit
    Internet Initiative Japan Inc. (http://www.iij.ad.jp/en/)

Index: evdns.c
===================================================================
--- evdns.c     (revision 1557)
+++ evdns.c     (working copy)
 <at>  <at>  -3304,7 +3304,8  <at>  <at> 
        if (!strcmp(first_token, "nameserver") && (flags & DNS_OPTION_NAMESERVERS)) {
                const char *const nameserver = NEXT_TOKEN;

-               evdns_base_nameserver_ip_add(base, nameserver);
+               if (nameserver)
+                       evdns_base_nameserver_ip_add(base, nameserver);
        } else if (!strcmp(first_token, "domain") && (flags & DNS_OPTION_SEARCH)) {
                const char *const domain = NEXT_TOKEN;
                if (domain) {

***********************************************************************
To unsubscribe, send an e-mail to majordomo <at> freehaven.net with
unsubscribe libevent-users    in the body.

Re: NULL access on resolv_conf_parse_line

On Fri, Dec 4, 2009 at 10:56 AM, Niels Provos <provos <at> gmail.com> wrote:
> thank you for your patch.   That is not fixed in the git repository.

What I meant to say is that your patch has been applied to the git
repository and the problem is fixed now.

Thanks,
Niels.
***********************************************************************
To unsubscribe, send an e-mail to majordomo <at> freehaven.net with
unsubscribe libevent-users    in the body.

Re: Welcome to libevent-users

> --
>
> Welcome to the libevent-users mailing list!
>
> Please save this message for future reference.  Thank you.
>
> If you ever want to remove yourself from this mailing list,
> you can send mail to <majordomo <at> seul.org> with the following
> command in the body of your email message:
>
>    unsubscribe libevent-users
>
> or from another account, besides rogerdpack2 <at> gmail.com:
>
>    unsubscribe libevent-users rogerdpack2 <at> gmail.com
>
> If you ever need to get in contact with the owner of the list,
> (if you have trouble unsubscribing, or have questions about the
> list itself) send email to <owner-libevent-users <at> seul.org> .
> This is the general rule for most mailing lists when you need
> to contact a human.
>
> #### No info available for libevent-users.

As a note, this introductory email didn't actually tell me how to post
to the mailing list.  Is this expected?

Twould be quite convenient to establish a google group mirror or what
not (just set the first post to moderated to avoid spammers).

Much thanks.

-r
***********************************************************************
To unsubscribe, send an e-mail to majordomo <at> freehaven.net with
unsubscribe libevent-users    in the body.

Re: NULL access on resolv_conf_parse_line

Hi Yasuoka,

thank you for your patch.   That is not fixed in the git repository.

Niels.
***********************************************************************
To unsubscribe, send an e-mail to majordomo <at> freehaven.net with
unsubscribe libevent-users    in the body.