Thoughts on Threads

[paulmansour]

Consider the case where we want to run a lot of very short-lived tasks, arriving via a websocket, in order. However, we don't want to them in the 0 thread, which must remain unblocked and available for other things.

There at least two solutions for this.

First, we can spawn a new thread for every task and then use ⎕TSYNC to ensure that each task waits for the previous task to finish before starting.

Second, we can create a single new permanent thread with a loop around ⎕TGET to process tasks that are chucked in from the main thread using ⎕TPUT.

I would have thought the latter would be a more efficient solution, especially as the volume of short-lived tasks grows. But that appears not to be the case, which leads me the believe that threads are much lighter resources than I thought.

[Morten|Dyalog]

Hi Paul, thanks for the question, as they say. I'm surprised, do you have some benchmark code that you could share with us?

P.S. Could you run the code that listens on the websocket in a thread other than 0? That's what I'm doing in my latest project.

[paulmansour]

Hi Morten. Yes, I will be able to have some code I can share, but probably a few weeks from now. I want to do some more tests and structure it a little better.

As for listening on the websocket in a different thread than 0, that's not exactly the issue. I have different message types arriving on the same websocket. The vast majority need to be handled sequentially, but some types do not need to wait - and can't wait - they must be handled immediately. Thus regardless of what thread I'm listening in, I have the same problem.

... but your suggestion does make me think about having multiple websockets... though that may complicate things...