Threads for polling


#1

Hi there,

I’m making huge steps understanding juce - unfortunally I got to a point where I need help again.

I’m working on a vst-plugin that connects to different udp-devices to collect data from them. When I look at the DatagramSocket, it seems like there’s no way around polling… So my idea was to spawn a thread for each device (= for each datagram socket) and poll for new data. New data would have to be inserted into a lock free linked list or similar. Then I would need another thread to go through all these lists of all devices and again collect the data to distribute it to the rest of my application.

So overall for say 6 devices I would spawn at least 7 threads. I’m not familar with multi-threading so far, but intuition tells me, that there must be a better solution than having so many thread simply waiting for something (= wasting CPU [?] )

Thanks for any hints,
StrangeMan


#2

A thread that is blocked on an operating system handle or WaitableEvent object does not consume resources.


#3

Hi Vinn!

Thanks for your reply! Good to know that the thread is “suspended” when waiting for these kind of events.
So my approach is fine? I checked my “task manager” and more than 1000 Threads were running under normal use. Sounds like it’s okay to have >20 threads running for one application…

StrangeMan


#4

Me personally, I would use asynchronous I/O and have one thread per operating system CPU (or just one thread period) handling UDP datagrams.

JUCE doesn’t support this use-case (nor should it, since the implementation is significantly non-trivial).

boost::asio on the other hand, supports it fully on all platforms.

1,000 threads seems like a lot.

If what you’re doing is working for you then by all means, continue with it for now since you can get on with the rest of your program. But if it ever becomes a problem, asynchronous I/O is the next step.


#5

I guess it’s better for me to keep my fingers away from this stuff unless it’s really neccessary.

See the image I attached. I’m running several programs at once. Though not too many. (BTW: the program I’m working on is not running :D)

Well, thanks anyway, I think that answered my question!

StrangeMan


#6

For non-blocking, low overhead socket polling, you should use select(). Not sure what juce uses. That can actually deal with a batch of sockets, and just let you know which ones have activity.

I use another sockets library that is great for comms. Not 100% compatible in approach with juce, but it’s workable.

http://www.alhem.net/Sockets/

Bruce