LibEvent, signals or communication between threads

[Sean Kelly]

On May 8, 2012, at 11:13 AM, Shadow_exe wrote:

> Thank You! As would there sometimes You have helped.
> But I'm afraid that these methods me not suitable because libevent already creates a queue and turn me not to come out to do.
> Information how to send that is the signal to the next thread I have not found this information that have been granted to You - I've read.
> 
> Okay, I will do through юниксовые sockets.

std.concurrency uses a condition variable internally to signal the waiting thread when new messages have arrived.  As this is an implementation detail, it isn't exposed to the user.

libevent is unfortunately somewhat limited in the events that can be monitored.  It's pretty much just read/write events on a file descriptor, so using a socket or pipe is about the only way to notify a thread blocked on a libevent queue.  libev is more flexible in the range of events it offers.  I believe there's even a user-triggered event, though I bet this still uses a pipe internally.  And you're still stuck with the problem of sending the message and then separately triggering the event.

Really, messaging doesn't seamlessly integrate with high-performance socket IO.  Once Phobos gets a better networking API I'd like to provide a shim to proxy data to/from a socket Erlang-style, but that approach is really only desirable for simple cases, and cases where performance isn't a significant concern (since it tends to involve a lot of memory churn).  Beyond that… maybe I can cook up some way to let the user plug a notification mechanism into the message queue, so when a message is received, if nothing is waiting on the condition variable the other notification mechanism is used instead.