RejectedSoftware Forums

On Tue, 04 Feb 2014 10:32:39 +0100, Sönke Ludwig wrote:

Am 04.02.2014 09:40, schrieb Damian Ziemba:

Hello.

I need help to get some basic things running up.

I would like to fire an event when data for read is available on file descriptor.

Something like this in C code:

event_new(event_base_new(), fd, EV_READ|EV_PERSIST, my_callback, obj);

but Vibed way. How can I achive that?

On GIT master, there is a generic createFileDescriptorEvent() function
in vibe.core.core that achieves this.

Hmm, is there any example how can I use it?
For example to print hello world on stdout when data for read is available?

Another thing I would like to listen on unix socket instead of IP address. How can I do it?
Can I do something like

listenTCP(0, callback, "/tmp/my.sock", options);

?

There is currently no direct support for UNIX sockets, so the usual BSD
socket calls need to be used manually in conjunction with the
FileDescriptorEvent. Dedicated support would be nice to have, but
unfortunately I'm currently lacking the time to implement them.

Roger that, I will try to help with that

Am 06.02.2014 13:41, schrieb Damian Ziemba:

On Tue, 04 Feb 2014 10:32:39 +0100, Sönke Ludwig wrote:

Am 04.02.2014 09:40, schrieb Damian Ziemba:

Hello.

I need help to get some basic things running up.

I would like to fire an event when data for read is available on file descriptor.

Something like this in C code:

event_new(event_base_new(), fd, EV_READ|EV_PERSIST, my_callback, obj);

but Vibed way. How can I achive that?

On GIT master, there is a generic createFileDescriptorEvent() function
in vibe.core.core that achieves this.

Another thing I would like to listen on unix socket instead of IP address. How can I do it?
Can I do something like

listenTCP(0, callback, "/tmp/my.sock", options);

?

There is currently no direct support for UNIX sockets, so the usual BSD
socket calls need to be used manually in conjunction with the
FileDescriptorEvent. Dedicated support would be nice to have, but
unfortunately I'm currently lacking the time to implement them.

I've started working on implementing that.
I should be able to make pull request today.

But I still don't know how to make working example with file descriptor.

You need to have an existing FD (a socket of some kind) that is set to
non-blocking mode. You then create a FileDescriptorEvent and use
wait in the same situation that you'd normally use select to wait
for data:

auto evt = createFileDescriptorEvent(fd, FileDescriptorEvent.Trigger.any);

// read someting
while (true) {
   auto ret = recv(fd, but.ptr, buf.length, 0);
   if (ret < 0 && errno == EWOULDBLOCK) {
     // wait until data is available for read
     evt.wait(FileDescriptorEvent.Trigger.read);
   } else {
     // handle error or received data
   }
}

Am 16.03.2016 um 06:51 schrieb denizzzka:

On Thu, 06 Feb 2014 14:04:37 +0100, Sönke Ludwig wrote:

You need to have an existing FD (a socket of some kind) that is set to
non-blocking mode.

Why it is important to have non-blocking socket in this case? I accidentally tried to use blocking socket and didn't seen difference.

It depends on the exact way the read/write loop is structured. But you
always have the risk of blocking the event loop if it isn't. However,
the event notification mechanism admittedly should usually work for
blocking FDs, too.

On Fri, 18 Mar 2016 05:04:25 GMT, denizzzka wrote:

On Thu, 06 Feb 2014 14:04:37 +0100, Sönke Ludwig wrote:

You need to have an existing FD (a socket of some kind) that is set to
non-blocking mode. You then create a FileDescriptorEvent and use
wait in the same situation that you'd normally use select to wait
for data:

auto evt = createFileDescriptorEvent(fd, FileDescriptorEvent.Trigger.any);

// read someting
while (true) {
   auto ret = recv(fd, but.ptr, buf.length, 0);
   if (ret < 0 && errno == EWOULDBLOCK) {
     // wait until data is available for read
     evt.wait(FileDescriptorEvent.Trigger.read);
   } else {
     // handle error or received data
   }
}

Just to make sure:

In this case there are will not created extra CPU thread for waiting socket event?

Events lib tracks events on the socket by the operating system functional (callbacks or something like from already existing OS thread)?

No, no new thread. In Linux it would typically use epoll_wait to wait for the next event within the same thread.