Re: [Libevent-users] Multi-threaded support in libevent

[Jan Danielsson <jan.m.danielsson@xxxxxxxxx>]

On 02/24/17 09:23, Tôn Loan wrote:
[---]
> Thank you for your useful advice. Actually, as  you said, if I let libevent
> handle the networking stuff within one thread, I wonder that is there a
> bottle neck that happens when client sends a lot of messages to four
> sockets?
[---]

   That reads to me like you're prematurely making assumptions about
bottlenecks.  Generally speaking -- as someone who learned to use
profilers far later than I should have:  The bottlenecks are often not
where you think they are.

   I would suggest you try for the simpler solution first (write a
quick'n'dirty prototype) and test a non-threaded version with a
test-client with sends worst-case amount of data.  Only if you notice
that it's having trouble handling the workload you start looking into a
threaded solution.  But more importantly, if your program can't keep up,
figure out why and work on the identified problem area.

   With regards to specific design suggestions, I have done sort-of what
you describe (receiving command UDP packets at a somewhat high rate, and
in my case processing them could sometimes take a while).  What I chose
to do after a little experimentation:  I receive all UDP packets on the
same thread and use queues (implemented as ring-buffers) to queue up the
data for one or more separate processing threads.  I.e. the "base
thread" only receives data and dispatches the heavy work to other
threads via queues.

   Getting these things right can take some trial and error; one thing
I'd advise is to look at what mature projects do, because they have
often (though not always) done all the mistakes and learned from them.

-- 
Kind regards,
Jan Danielsson

***********************************************************************
To unsubscribe, send an e-mail to majordomo@xxxxxxxxxxxxx with
unsubscribe libevent-users    in the body.