>> - remove trailing commas in enums in eio.h (since C++ does not allow them).
>
> Hmm, libeio is C, not C++, but even C++ does allow trailing commans in
> enums, see 7.2p1:
>
> enum-specifier:
>enum-head { enumerator-list(opt) }
>enum-head { enumerator-list , }
But it can be u
Hi,
Please find here: http://paste.pocoo.org/raw/561723/ a patch against the
current version of libeio.
This patch addresses 2 things (mainly linked to ease of use in C++):
- remove trailing commas in enums in eio.h (since C++ does not allow them).
- add an opaque applicative pointer in eio_ini
Le 13 oct. 2011 à 08:12, sai koushik a écrit :
> Hi ,
>
> i tried to crate a socket client using libev , and this client has to listen
> for data from the server.
> and i tried as below
> ev_io stdin_watcher;
>
> sock_fd = socket(PF_UNIX, SOCK_STREAM, 0);
>
> Thanks Pierre-Yves!
> I modified my code setting non-blocking socket using the way you described.
> The problem is still the same.
You need to listen(fd, backlog) on your server socket before attempting to
connect. How about something like this:
#include
#include
#include
#include
int se
> Well, I've just found out why the "Invalid file descriptor" was generated. I
> didn't stop the "read watcher" when creating the "write watcher".
>
> So, I just maintain my second question:
> What's the most convenient way to write data in a TCP socket:
> 1.- "send" data directly in the read
Hi Cong,
> I'm a newbie to libev. I wrote a TCP server with libev. My program has a
> relatively simple structure, with accept_cb, read_cb, write_cb and timeout_cb
> defined. However, when I started it, I found the accept call back is called
> right away and being called about 60K+ times per se
> We use libev in Linux (2.6.35 on big/small endian ARM) for a simple
> network client application where we want to timeout connect() attempts.
>
> http://www.unixguide.net/network/socketfaq/3.5.shtml
>
> For this purpose we use the following construct in a libev callback.
>
>timeo
> On Wed, Mar 30, 2011 at 03:27:04PM +1100, Arlen Cuss
> wrote:
>> I enjoyed reading your (many) comments in the documentation talking
>> about the same :-P, particularly "a frankenpoll" re: epoll.
>
> It's a direct consequence of my many frustrated workarounds and insightful
> moments ("ugh").
> On Wed, Mar 30, 2011 at 03:27:04PM +1100, Arlen Cuss
> wrote:
>> I enjoyed reading your (many) comments in the documentation talking
>> about the same :-P, particularly "a frankenpoll" re: epoll.
>
> It's a direct consequence of my many frustrated workarounds and insightful
> moments ("ugh").
>> Thanks for the thorough explanation. I'm actually developing a fast socket
>> server that will be using a storage backend library to store thousands of
>> millions of "small objects" (basically less than 1K) in a large optimized
>> hash table. This storage layer maintains a large objects cache
> On Wed, Dec 30, 2009 at 03:26:03PM -0600, Brandon Black
> wrote:
>> What he's referring to is that in the general case, a multi-process
>> program will scale better over increasingly large core counts than a
>> multi-threaded program, because the shared address space of the
>> threads tends to
>> Thanks for your fast answer. If I correctly understand what you're saying,
>> the same ev_async watcher started ev_async_init()-ed and ev_async_start()-ed
>> in each worker thread has to be passed to the ev_async_send() call ? It
>> means it cannot be a local variable anymore and has to be acc
>> Your experience is interesting, but I have a question: why do you need
>> threads in event-driven machine? I just tested my app based on libev,
>> it works as followed:
>>
>> bind();
>> listen();
>>
>> for (i = 0; i < 4; ++i)
>> {
>> switch (fork())
>> {
>> case -1: /* epic fail */ break
Hello Denis,
> Your experience is interesting, but I have a question: why do you need
> threads in event-driven machine? I just tested my app based on libev,
> it works as followed:
>
> bind();
> listen();
>
> for (i = 0; i < 4; ++i)
> {
>switch (fork())
>{
>case -1: /* epic fail */
Hi Marc,
Thanks for your fast answer. If I correctly understand what you're saying, the
same ev_async watcher started ev_async_init()-ed and ev_async_start()-ed
in each worker thread has to be passed to the ev_async_send() call ? It means
it cannot be a local variable anymore and has to be acces
Hi list,
I'm quite new to libev and I'm having a hard time figuring out why a call to
ev_async_send() will not trigger the corresponding async handler
in the specified target loop. I'm using the following exercizer program, where
the main thread basically starts an event loop to monitor network
16 matches
Mail list logo
