On Wed, Sep 16, 2015 at 5:09 PM, Devchandra Meetei <[email protected]> wrote:
> Hey libuvers
>
> Requesting your expert input.
>
> uv_queue_work is the way to go for handing out to a thread pool and get the
> result. and we don't want to touch this for our library.
> Thread pool will be reserved for the app developer.
>
> What I am trying is to hand out CPU intensive work like SSL handshake and
> processing to a
> dedicated thread. The thread blocks on a condition var and inform the loop
> about processed data availability. This will involve
> something like
> 1) get data from network, then write the data to SSL processor and signal
> the thread.
> Approach: We will use a thread, mutex, and condition_var for this
>
> 2) thread processes the data and wake up the loop upon completion
> Question:- will uv_async_send() be better for the wakeup? or writing
> something to the socket fd will be better?
>
>
> Thanks in advance.

uv_queue_work() is implemented in terms of condition variables and
uv_async_t handles to wake up the event loop, so it looks like you're
already moving in the right direction.  I suggest sticking to
uv_async_send() because it can get optimized in ways that writing to a
file descriptor never will.

-- 
You received this message because you are subscribed to the Google Groups 
"libuv" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/libuv.
For more options, visit https://groups.google.com/d/optout.

Reply via email to