looking at libevent cvs i see starting at line 562:
gettime(&now);
timersub(&ev->ev_timeout, &now, &res);
/* correctly remap to real time */
gettimeofday(&now, NULL);
timeradd(&now, &res, tv);
shouldn't that gettimeofd
event.c says this:
/* Handle signals - This is a deprecated interface */
int (*event_sigcb)(void); /* Signal callback when gotsig
is set */
volatile sig_atomic_t event_gotsig; /* Set in signal handler */
However, the man page says nothing about this.
I guess that despite the la
Hello, all ...
I'm using libEvent to write a streaming media server, mainly to test
epoll() on Linux / kqueue on Mac OSX / etc. for scalability. Right
now, my test server waits for n connections to be established (n
specified on the command line), calling event_add() for each
connection
At Sat, 22 Apr 2006 01:24:24 -0700, [EMAIL PROTECTED] wrote:
> Hello, all ...
>
> I'm using libEvent to write a streaming media server, mainly to test
> epoll() on Linux / kqueue on Mac OSX / etc. for scalability. Right
> now, my test server waits for n connections to be established (n
> sp
It seems there is no efficient way to change the timeout
of a persistent event?
This might be desired for example to have a different timeout
while reading bytes within a message, than a timeout between
messages on the same socket.
An alternative solution might be two have two different
timers, o
If all your sockets really are non-blocking (which you better
double-check),
I can only understand the behavior you describe as being one where
those big writes are never seeing EWOULDBLOCK, and so never have
reason to stop.
That would probably mean you are doing localhost testing,
or on a very fas
Richard,
I'm using libEvent to write a streaming media server, mainly to test
epoll() on Linux / kqueue on Mac OSX / etc. for scalability. Right
now, my test server waits for n connections to be established (n
specified on the command line), calling event_add() for each
connection, then calls
At Sat, 22 Apr 2006 02:50:25 -0700, [EMAIL PROTECTED] wrote:
>
> Richard,
>
> > Make the socket you accept on non blocking and register a read
> > callback for it. Accept new connections in the callback.
>
> Yes, I can do this, but maybe a better way is to (yes, John finally
> read _that_ part o
Richard,
Ask yourself why you use libevent :)
If I understand you correctly (which I quite possibly don't) you
propose
something like this:
for(;;) {
accept_new_connections(); /* Doesn't block */
event_loop(EVLOOP_NONBLOCK);
}
But this negates the point of libevent since you're no
in event.c cvs, in event_base_free there is:
assert(TAILQ_EMPTY(&base->eventqueue));
this assert fails, because there is typically still the internal event
ev_signal from signal.c still on the queue.
Right now, there is nothing the outside programmer can do about that,
as far as i can see --
Bug reports work the best if their are accompanied by patches and a
unittest that proves them.
Thank you,
Niels.
On 4/22/06, Mark D. Anderson <[EMAIL PROTECTED]> wrote:
> in event.c cvs, in event_base_free there is:
> assert(TAILQ_EMPTY(&base->eventqueue));
>
> this assert fails, because th
On Sat, 22 Apr 2006 14:04:48 -0700, "Niels Provos"
<[EMAIL PROTECTED]> said:
> Bug reports work the best if their are accompanied by patches and a
> unittest that proves them.
Ok, here they are.
Mind you, I have no idea what the contracts are with internal events,
so I have no idea whether this is
12 matches
Mail list logo
