On Fri, Sep 9, 2011 at 12:32 AM, Scott Lamb wrote:
> I see your point, fwiw. I just wish it were possible to do much better
> than that, but I don't think it is given the available OS interfaces.
> One could imagine a bufferevent implementation that used aio, though
> I'm no
that used aio, though
I'm not sure what OSs have a satisfactory aio implementation...
>
> Anyway, I agree 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 Th
wrong here, but while you can technically have a file
>> descriptor set to non-blocking, you are still limited to flush
>> operations which result in CPU waits. This can result in blocking.
>>
>> ***
>> To u
event_add(&fd_write, NULL);
>> }
>> }
>>
>> int main(int argc, char** argv)
>> {
>> full = 0;
>>
>> event_init();
>>
>> printf("Starting.\n");
>>
>> int fd;
&g
nder discussion, etc.
And above all, I'm sorry if I gave you the impression that I'm pissed
off or bear any ill will toward you. I just want good software. You
didn't convince me this time, but it's nothing personal.
--
Scott Lamb <http://www.slamb.org/>
**
On Wed, May 11, 2011 at 11:21 AM, Scott Lamb wrote:
> On Wed, May 11, 2011 at 10:12 AM, Cliff Frey wrote:
>> I spent some more time thinking about this, and I have a few use cases that
>> it might be worth keeping in mind.
>>
>> It would be nice if the API made it easy
that allows for flow control
>> struct bufferevent *evhttp_send_reply_bev(struct evhttp_request *req,
>> int code, const char *reason);
>> It is the caller's responsibility to fill the returned bufferevent with
>> the data to be sent to the client, and to eventu
On Tue, May 10, 2011 at 9:11 PM, Mark Ellzey wrote:
> On Tue, May 10, 2011 at 04:04:27PM -0700, Scott Lamb wrote:
>> I don't see the point in libevent implementing spooling to a file
>> (descriptor). If an application wants that, it can implement it on to
On Tue, May 10, 2011 at 4:04 PM, Scott Lamb wrote:
> On Tue, May 10, 2011 at 4:46 AM, Mark Ellzey wrote:
>> On Tue, May 10, 2011 at 09:04:42AM +0200, Roman Puls wrote:
>>> whilst this might be nice for flow-blown web services, this does not
>>> work for embedded s
the same function for chunks for both server and client..
>
> The solution was to add a secondary callback that gave you access to a
> request post-header-parsing / pre-body-read, at which time you could set
> the chunk callback previously accessible only to clients.
+
o address this, and you
can even resize those with SO_SNDBUF and SO_RCVBUF as desired. So
maybe Cliff's approach is fine.
>
> But on consideration, this code is pretty darn nice. I'm hoping other
> evhttp users will have a look at it too, but on the whole I am pretty
sense with event_base_loopbreak.
>
> Am I missing something ?
>
> ***
> To unsubscribe, send an e-mail to majord...@freehaven.net with
> unsubscribe libevent-users in the body.
--
Scott Lamb <http://www.slamb.org/>
***
To unsubscribe, send an e-mail to majord...@freehaven.net with
unsubscribe libevent-usersin the body.
at means that there's already a wake-up queued. Unless the main
thread does as little as possible on each wake-up (which would seem
odd), that's all you need. A return of -1/EAGAIN is just as good as a
return of 0 in this case.
> *
13 matches
Mail list logo
