Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Varnish: Dev

r96 - trunk/varnish-cache/bin/varnishd

 

 

Varnish dev RSS feed   Index | Next | Previous | View Threaded


des at linpro

Apr 3, 2006, 4:07 AM

Post #1 of 6 (241 views)
Permalink
r96 - trunk/varnish-cache/bin/varnishd

phk at projects.linpro.no writes:
> Log:
> How I wish people would think more ahead when writing libraries like
> libevent. The entire "implicit event engine" api assumption stinks.

Can you explain what's wrong with it?

DES
--
Dag-Erling Sm?rgrav
Senior Software Developer
Linpro AS - www.linpro.no


des at linpro

Apr 3, 2006, 4:07 AM

Post #2 of 6 (225 views)
Permalink
r96 - trunk/varnish-cache/bin/varnishd [In reply to]

phk at projects.linpro.no writes:
> Log:
> How I wish people would think more ahead when writing libraries like
> libevent. The entire "implicit event engine" api assumption stinks.

Can you explain what's wrong with it?

DES
--
Dag-Erling Sm?rgrav
Senior Software Developer
Linpro AS - www.linpro.no


phk at phk

Apr 3, 2006, 4:30 AM

Post #3 of 6 (224 views)
Permalink
r96 - trunk/varnish-cache/bin/varnishd [In reply to]

In message <ujrodzikjcr.fsf at cat.linpro.no>, Dag-Erling =?iso-8859-1?Q?Sm=F8rgra
v?= writes:
>phk at projects.linpro.no writes:
>> Log:
>> How I wish people would think more ahead when writing libraries like
>> libevent. The entire "implicit event engine" api assumption stinks.
>
>Can you explain what's wrong with it?

Here is the email I just sent to Niels Provos:

>============================================================================
>From: Poul-Henning Kamp <phk at phk.freebsd.dk>
>Subject: libevent, some comments.
>To: provos at citi.umich.edu
>Message-Id: <12019.1144063692 at critter.freebsd.dk>
>Date: Mon, 03 Apr 2006 13:28:12 +0200
>
>
>Please don't take this the wrong way, it is meant to be a constructive
>critisism of libevent.
>
>The background is that I'm writing an application (OSS) which needs
>several event engines in multiple threads and a lot of other
>quasinasty stuff.
>
>My choice was between ISC/s eventlib and your libevent and my initial
>choice where to go with your libevent because of the kqueue support.
>
>Against your libevent counts that the API is quite a mess by now,
>and a far cry from the very stringent and quite fool-proof API
>of the ISC library.
>
>Having gotten somewhat down the road now, I feel that I'm in a position
>to point out a number of improvements to libevent which could make
>it a better proposition for "the default event library".
>
>I hope you'll consider my input.
>
>Poul-Henning
>
>PS: If you're going to be at BSDcan in Ottawa, we can find some time
>and hash the details out if you like.
>
>1: Multi engine support is a mess.
>----------------------------------
>
>The fact that multiple eventengines in the same namespace is bolted
>on later has two unfortunate effects: It messes up the namespace
>with foo_base_bar() functions and it leaves a giant hole for messing
>things up if people are not very very alert.
>
>I would recommend (and be willing to do a lot of the work) that
>a v2 of libevent is created by taking the current sources, making
>the eventbase mandatory throughout and start a new and more systematic
>namespace ("evb_foo()" or "evl_foo()" ?)
>
>A trivial layer of wrapper macros can then implement the current
>ABI, on top of the new one so that nobody will have to rewrite their
>apps unless they want to.
>
>
>2: Timestamp handling
>---------------------
>
>I would recommend is that you adobt some of the time-handling
>facilities from named/ISC's eventlibrary.
>
>Passing a struct timespec instead of a pointer to it may offend old
>C-coders like us, but it makes for much cleaner source code for the
>users:
>
> struct timespec foo;
>
> foo.tv_sec = 1;
> foo.tv_nsec = 0;
> evtimer_mumble(ev, &foo)
>
>vs
>
> evtimer_mumble(ev, TimeSpec(1, 0))
>
>The TimeSpec function looks like this:
>
> struct timespec
> TimeSpec(time_t sec, long nsec)
> {
> struct timespec ts;
>
> ts.tv_sec = sec;
> ts.tv_nsec = nsec;
> return (ts);
> }
>
>And yes, that is legal in all but the most antique compilers.
>
>The advantage of this is that it eliminates the memory management
>for the timestamps out of the users responsibility.
>
>The big advantage comes once you have to start doing math on
>your timestamps:
>
> evtime_mumble(ev, TimeAdd(default_timeout, TimeSpec(10, 0)));
>
>
>
>3: Use CLOCK_MONOTONIC
>----------------------
>
>An eventlibrary should use CLOCK_MONOTONIC to avoid being affected
>by clock-steps from NTPD or similar.
>
>If UTC timing is required, an per event-engine option could switch
>to CLOCK_REALTIME.
>
>
>4: Be carefull with layered facilities
>--------------------------------------
>
>As convenient as http support is, not everybody will need it,
>and for others usurping the http_* and HTTP_* namespace will
>be a major problem in using libevent.
>
>I would propose that the http support be put in a separate
>library or at the very least hidden under a
>
> #ifndef I_DO_NOTWANT_LIBEVENT_HTTP_SUPPORT
>
>so that the namespace polution can be avoided.
>
>--
>Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
>phk at FreeBSD.ORG | TCP/IP since RFC 956
>FreeBSD committer | BSD since 4.3-tahoe
>Never attribute to malice what can adequately be explained by incompetence.

--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.


phk at phk

Apr 3, 2006, 4:30 AM

Post #4 of 6 (223 views)
Permalink
r96 - trunk/varnish-cache/bin/varnishd [In reply to]

In message <ujrodzikjcr.fsf at cat.linpro.no>, Dag-Erling =?iso-8859-1?Q?Sm=F8rgra
v?= writes:
>phk at projects.linpro.no writes:
>> Log:
>> How I wish people would think more ahead when writing libraries like
>> libevent. The entire "implicit event engine" api assumption stinks.
>
>Can you explain what's wrong with it?

Here is the email I just sent to Niels Provos:

>============================================================================
>From: Poul-Henning Kamp <phk at phk.freebsd.dk>
>Subject: libevent, some comments.
>To: provos at citi.umich.edu
>Message-Id: <12019.1144063692 at critter.freebsd.dk>
>Date: Mon, 03 Apr 2006 13:28:12 +0200
>
>
>Please don't take this the wrong way, it is meant to be a constructive
>critisism of libevent.
>
>The background is that I'm writing an application (OSS) which needs
>several event engines in multiple threads and a lot of other
>quasinasty stuff.
>
>My choice was between ISC/s eventlib and your libevent and my initial
>choice where to go with your libevent because of the kqueue support.
>
>Against your libevent counts that the API is quite a mess by now,
>and a far cry from the very stringent and quite fool-proof API
>of the ISC library.
>
>Having gotten somewhat down the road now, I feel that I'm in a position
>to point out a number of improvements to libevent which could make
>it a better proposition for "the default event library".
>
>I hope you'll consider my input.
>
>Poul-Henning
>
>PS: If you're going to be at BSDcan in Ottawa, we can find some time
>and hash the details out if you like.
>
>1: Multi engine support is a mess.
>----------------------------------
>
>The fact that multiple eventengines in the same namespace is bolted
>on later has two unfortunate effects: It messes up the namespace
>with foo_base_bar() functions and it leaves a giant hole for messing
>things up if people are not very very alert.
>
>I would recommend (and be willing to do a lot of the work) that
>a v2 of libevent is created by taking the current sources, making
>the eventbase mandatory throughout and start a new and more systematic
>namespace ("evb_foo()" or "evl_foo()" ?)
>
>A trivial layer of wrapper macros can then implement the current
>ABI, on top of the new one so that nobody will have to rewrite their
>apps unless they want to.
>
>
>2: Timestamp handling
>---------------------
>
>I would recommend is that you adobt some of the time-handling
>facilities from named/ISC's eventlibrary.
>
>Passing a struct timespec instead of a pointer to it may offend old
>C-coders like us, but it makes for much cleaner source code for the
>users:
>
> struct timespec foo;
>
> foo.tv_sec = 1;
> foo.tv_nsec = 0;
> evtimer_mumble(ev, &foo)
>
>vs
>
> evtimer_mumble(ev, TimeSpec(1, 0))
>
>The TimeSpec function looks like this:
>
> struct timespec
> TimeSpec(time_t sec, long nsec)
> {
> struct timespec ts;
>
> ts.tv_sec = sec;
> ts.tv_nsec = nsec;
> return (ts);
> }
>
>And yes, that is legal in all but the most antique compilers.
>
>The advantage of this is that it eliminates the memory management
>for the timestamps out of the users responsibility.
>
>The big advantage comes once you have to start doing math on
>your timestamps:
>
> evtime_mumble(ev, TimeAdd(default_timeout, TimeSpec(10, 0)));
>
>
>
>3: Use CLOCK_MONOTONIC
>----------------------
>
>An eventlibrary should use CLOCK_MONOTONIC to avoid being affected
>by clock-steps from NTPD or similar.
>
>If UTC timing is required, an per event-engine option could switch
>to CLOCK_REALTIME.
>
>
>4: Be carefull with layered facilities
>--------------------------------------
>
>As convenient as http support is, not everybody will need it,
>and for others usurping the http_* and HTTP_* namespace will
>be a major problem in using libevent.
>
>I would propose that the http support be put in a separate
>library or at the very least hidden under a
>
> #ifndef I_DO_NOTWANT_LIBEVENT_HTTP_SUPPORT
>
>so that the namespace polution can be avoided.
>
>--
>Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
>phk at FreeBSD.ORG | TCP/IP since RFC 956
>FreeBSD committer | BSD since 4.3-tahoe
>Never attribute to malice what can adequately be explained by incompetence.

--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.


des at linpro

Apr 3, 2006, 5:08 AM

Post #5 of 6 (225 views)
Permalink
r96 - trunk/varnish-cache/bin/varnishd [In reply to]

"Poul-Henning Kamp" <phk at phk.freebsd.dk> writes:
> As convenient as http support is, not everybody will need it,
> and for others usurping the http_* and HTTP_* namespace will
> be a major problem in using libevent.
>
> I would propose that the http support be put in a separate
> library or at the very least hidden under a
>
> #ifndef I_DO_NOTWANT_LIBEVENT_HTTP_SUPPORT
>
> so that the namespace polution can be avoided.

The middle road would be to move macros and prototypes for the HTTP
functionality to a separate header. This shouldn't break any existing
software, since the HTTP code is not present in any released version
of libevent.

DES
--
Dag-Erling Sm?rgrav
Senior Software Developer
Linpro AS - www.linpro.no


des at linpro

Apr 3, 2006, 5:08 AM

Post #6 of 6 (225 views)
Permalink
r96 - trunk/varnish-cache/bin/varnishd [In reply to]

"Poul-Henning Kamp" <phk at phk.freebsd.dk> writes:
> As convenient as http support is, not everybody will need it,
> and for others usurping the http_* and HTTP_* namespace will
> be a major problem in using libevent.
>
> I would propose that the http support be put in a separate
> library or at the very least hidden under a
>
> #ifndef I_DO_NOTWANT_LIBEVENT_HTTP_SUPPORT
>
> so that the namespace polution can be avoided.

The middle road would be to move macros and prototypes for the HTTP
functionality to a separate header. This shouldn't break any existing
software, since the HTTP code is not present in any released version
of libevent.

DES
--
Dag-Erling Sm?rgrav
Senior Software Developer
Linpro AS - www.linpro.no

Varnish dev RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.