Re: [Libevent-users] Linux, epoll, libevent, regressions, stability, and 2.0.9

[Chris Ross <chris@xxxxxxxxxxxxxx>]

I'm writing this as someone who uses 1.4 extensively and is considering the migration to 2.x.

I consider a change between 1 and 2 a major version change.

I would not feel hard done by if the behaviour changes between major release version for good reason - in the case of libevent, performance is an exceptional reason. Restricting yourself between major version changes is noble but will, as this situation has shown, stifle forward movement.

I do not consider a change from 2.0 to 2.1 a major version change and thus would feel a little frustrated if such an issue cropped up.

Given that this revolves around dup, epoll and epoll_ctl, would it not be useful to add a "promoted" api wrapper around that behaviour that handles this issue intelligently? Perhaps a drop in replacement for dup?

Hope this helps,

Chris

On 20 Nov 2010, at 08:25, Nick Mathewson wrote:

> I come to you with a heavy heart.

> [snip]

> Here are the two options that I *am* considering:
>  * Include both backends; make the existing changelist backend on by
> default.  The problem here is that it represents a genuine regression
> against Libevent 1.4, and I really hate having regressions.  A library
> that accepts regressions for well-formed code using older versions is
> IMO being very rude to its users, and encouraging people to worry
> about upgrading.
>  * Include both backends; make the non-changelist backend on by
> default.  The problems here are that a) the non-changelist backend is
> slower, and most people won't do whatever is necessary to activate the
> faster one, and b) the non-changelist backend has had not nearly so
> much testing as the current changelist-based backend.  If we do this,
> the lack of testing means we cannot possibly call 2.0.9
> "2.0.9-stable"; we'll need to call it "-rc" instead. :/
> 
> I am currently leaning towards the last option.  Efficiency is
> important, but even more important is knowing that if you wrote a
> program using Libevent version N, your program will still work when
> Libevent N+1 is released.  Setting an option to enable extra
> performance is more important than setting an option to enable
> backward compatibility.
> 
> Or at least that's what I think tonight.  Please, let me know if I'm
> wrong.  But keep in mind that if you argue that it's okay for Libvent
> 2.0 to break a well-behaved Libevent 1.4 program, you are also arguing
> that it's okay for Libevent 2.1 to break any program that you are
> writing for Libevent today.
> 
> Software-is-hard.-Let's-go-shopping-ly yrs,
> -- 
> Nick
> ***********************************************************************
> To unsubscribe, send an e-mail to majordomo@xxxxxxxxxxxxx with
> unsubscribe libevent-users    in the body.

***********************************************************************
To unsubscribe, send an e-mail to majordomo@xxxxxxxxxxxxx with
unsubscribe libevent-users    in the body.