On Thu, Aug 19, 2010 at 04:05:32PM -0400, Nick Mathewson wrote:
> On Wed, Aug 11, 2010 at 3:16 PM, Thor Lancelot Simon wrote:
> > On Tue, Aug 10, 2010 at 04:27:47PM -0700, Gilad Benjamini wrote:
> >>
> >> What are the major benefits of 2.0 ?
> >
> > From my point of view, a lot of convenience code
Why don't you send me a proper bug report and I'll have a look? This is
more likely a tmux issue than libevent.
The tmux FAQ has details on what you need to include.
There is no point in doing that until you have tried tmux CVS HEAD or at
least 1.3.
On Mon, Aug 30, 2010 at 03:30:10AM +0200, Mar
Maybe not too much help but it seems like strace would answer
possibilities 1, 2 and 3, that's how I typically track what is happening
with epoll inside libevent.
On Fri, Oct 22, 2010 at 01:38:45PM -0400, Nick Mathewson wrote:
> [summary: Nick looks for a bug, and finds only weirdness. But I thi
If this is right it seems really stupid and inconvenient. Sounds more
like a bug to me.
I add dup()d fds to libevent and haven't had any complaints from Linux
users. Although I don't remove and add them (or read and write from both
at the same time, I think).
dup()d fds definitely seems to work w
On a quick look it seems to me like epoll keys the tree on the epoll fd
by both underlying struct file and the file descriptor itself, so it
should work with dup()d fds.
On Fri, Oct 22, 2010 at 08:42:13PM +0100, Nicholas Marriott wrote:
> If this is right it seems really stupid and inconveni
to
add it it has the same struct file pointer and the same fd, and is
already on the tree.
On Fri, Oct 22, 2010 at 09:05:33PM +0100, Nicholas Marriott wrote:
> On a quick look it seems to me like epoll keys the tree on the epoll fd
> by both underlying struct file and the file descriptor
I think something needs to walk the file->f_ep_links list on close() and
remove any epitems where epi->ffd->fd is the fd being closed from the
tree in epi->ep.
I don't have a Linux box to try this on though :-).
On Fri, Oct 22, 2010 at 09:15:26PM +0100, Nicholas Marriott wrote
Hi
On Sun, Oct 24, 2010 at 01:03:25PM -0400, Nick Mathewson wrote:
> On Fri, Oct 22, 2010 at 4:25 PM, Nicholas Marriott
> wrote:
> > I think something needs to walk the file->f_ep_links list on close() and
> > remove any epitems where epi->ffd->fd is the fd being clos
This kernel bug is entirely nonobvious so personally I'd either drop the
changelist version entirely for now or default to the conservative
version.
If the latter, people who want the improved performance and understand
that the program they are using will work fine can turn it on (or
recommend to
Hi
Obviously it is ultimately up to you how you want to support things but
I'd just say that with a limited development team it is probably best to
avoid hard and fast support commitments.
I think a lot of small open source projects get bogged down in writing
and following rules and policies when
AFAIK this optimization in Linux is only available on some architectures
and there is a knob with several possible settings.
Without this, gettimeofday() can be quite expensive.
On Wed, Jul 27, 2011 at 01:10:05PM -0700, William Ahern wrote:
> On Wed, Jul 27, 2011 at 02:49:26PM -0400, Nick Mathew
Interesting.
We have seen problems in the past with gettimeofday() not being very
deterministic on Linux, with occasional spikes in the time it takes,
although I don't have the numbers to hand (50-100 microseconds or so are
the numbers I remember offhand).
If this is to be used as a basis for wha
OpenBSD is libevent 1.4.13.
OS X polling mechanisms are pretty bad: their poll() and kqueue() only
support sockets, so you will need to use select (set EVENT_NOPOLL=1
EVENT_NOKQUEUE= in the environment).
On Thu, Sep 01, 2011 at 11:19:52PM +0100, Bernd Schoeller wrote:
> Dear List,
>
> I am curr
On Thu, Sep 08, 2011 at 01:17:22AM -0700, Scott Lamb wrote:
> On Tue, Sep 6, 2011 at 3:25 AM, Nicholas Marriott
> wrote:
> > OpenBSD is libevent 1.4.13.
> >
> > OS X polling mechanisms are pretty bad: their poll() and kqueue() only
> > support sockets, so yo
It is however true to say that files will always return as readable and
writable but that still means kqueue and poll and hence libevent works
:-).
On Thu, Sep 08, 2011 at 04:44:26PM +0100, Nicholas Marriott wrote:
> On Thu, Sep 08, 2011 at 01:17:22AM -0700, Scott Lamb wrote:
> > On T
Yes you can't rely on file operations being nonblocking but in many
cases that doesn't matter - the real problem is that if you can't manage
file descriptors that point to real files with libevent it isn't
possible to use it for things such as stdout which the user can easily
change between a tty,
ee that if you are working on files alone then libevent is
unnecessary. If you just want to play either use sockets or avoid OS X
or force it to use select ;-).
On Thu, Sep 08, 2011 at 09:40:02AM -0700, Scott Lamb wrote:
> On Thu, Sep 8, 2011 at 9:16 AM, Nicholas Marriott
> wrote:
> >
Forwarding this message to ML at Nick's request...
Hi
You may remember a few months ago you fixed a problem with kqueue and
EPIPE on pipes - I backported this fix to 1.4 and recently applied it to
OpenBSD.
However, this is causing problems with Google Chrome. From what we can
gather it appears t
Well, fix libevent because we can't debug Google Chrome. Pretty sure
libevent should try to be consistent here in what it does.
Chrome is so big it makes our gdb freak out when built with symbols so
it gets a little tricky... feel free to give it a go :-).
On Wed, Feb 08, 2012 at 08:42:32AM -08
On Wed, Feb 08, 2012 at 11:37:45AM -0500, Nick Mathewson wrote:
> On Tue, Feb 7, 2012 at 1:47 PM, Nicholas Marriott
> wrote:
> > Forwarding this message to ML at Nick's request...
> >
> > Hi
> >
> > You may remember a few months ago you fixed a probl
On Wed, Feb 08, 2012 at 11:37:45AM -0500, Nick Mathewson wrote:
> On Tue, Feb 7, 2012 at 1:47 PM, Nicholas Marriott
> wrote:
> > Forwarding this message to ML at Nick's request...
> >
> > Hi
> >
> > You may remember a few months ago you fixed a probl
Ah, hmm... I've checked FreeBSD and it is the same, EPIPE, I don't have
a NetBSD box but I might be able to set one up tomorrow night if nobody
with one speaks up.
On Wed, Feb 08, 2012 at 09:16:41PM -0500, Nick Mathewson wrote:
> On Wed, Feb 8, 2012 at 12:19 PM, Nicholas Marr
istent. It sort of sucks not being able to tell which end was
closed.
On Thu, Feb 09, 2012 at 04:50:14PM -0500, Nick Mathewson wrote:
> On Thu, Feb 9, 2012 at 3:37 PM, Frank Denis wrote:
> > Le Thu, Feb 09, 2012 at 03:23:32PM -0500, Nick Mathewson ecrivait :
> >> On Thu, Feb 9, 2
Hi
FWIW in my experience your second idea would be a common solution
(queuing a new event to move the free on to the dispatch thread where it
can be guaranteed the event's callbacks are all done).
On Fri, Feb 24, 2012 at 09:34:12PM -0500, Nick Mathewson wrote:
> On Fri, Feb 24, 2012 at 8:14 PM,
24 matches
Mail list logo
