0

I want to create threads on the server that wait for work. I want 1 thread per user that visits the site. It works creating a while loop with thead.sleep(100) but that seems not efficient. We keep track of each task that belongs to each visitor so we can access their winform related objects.

So we need threads because we have put many years in winforms and much code is in forms code-behind so we have to start up an instance of the MainForm for each user and keep that in memory while the user is visiting the site. The html UI is pretty dumb and just responds to signals our socket is providing (like opening messagebox or small forms). For messagebox for example (yes/no) the server has to wait for choice of user before continue the process.

It's initial bad design forces us to take this approach which works and is fast. I only want to replace the waiting loops by something better (easier/faster). We can't redo it completely as it would cost 1year extra to develop

Maybe rx.NET can help but i'm unkown to that.

There is some relevant answer here but it's not obvious.

Thanks

Felix

Community
  • 1
  • 1
flieks
  • 175
  • 1
  • 3
  • 13
  • 6
    Winforms related objects on a website? One thread per user? Busy loops with Thread.Sleep? What are you trying to do, exactly, and why do you think multi-threading is a good solution? – Luaan Sep 29 '16 at 16:11
  • If all you're doing is waiting for results from some kind of IO, you don't want to create separate threads for this as the .NET framework already has numerous mechanisms available for non-blocking I/O. – EJoshuaS - Stand with Ukraine Sep 29 '16 at 16:31
  • Thanks, we need threads because we have put many years in winforms and much code is in code-behind (no api) so we have to startup an instance of the Main Form for each user and keep that in memory while the user is visiting the site. The html UI is pretty dumb and just responds to signals our socket is providing (like opening messagebox or small forms). For messagebox for example (yes/no) the server has to wait for choice – flieks Sep 30 '16 at 06:20
  • i have added more info to my question. Please reopen :) – flieks Oct 04 '16 at 07:12
  • There's a good way to approach this (separate business logic away from UI concerns, then reuse this logic in a website) and ... whatever it is that you're trying to do. Trying to run your windows forms apps on the server because your logic is horribly intertwined with UI concerns is just not going to work. – Damien_The_Unbeliever Oct 04 '16 at 07:15
  • Sorry, we know it's horrible but we cannot spend 1 year extra beginning from 0. Our approach now is fast and works. I only want to replace the waiting loops by something better (easier/faster). Please help with something more usefull. – flieks Oct 05 '16 at 13:28

1 Answers1

1

Correct me if I'm misreading your question but my understanding is that when users do the call in question, it involves some kind of potentially lengthy I/O.

Threads are not a good choice if all you're doing is waiting for a result of some kind. Creating additional threads is mostly good for CPU-bound work but the advantage of using them is much less clear if all you're doing is waiting for something to happen.

You really need to replace this with some kind of asynchronous or non-blocking I/O.

My standard illustration of this fact is as follows: suppose you go a restaurant with 10 people. When the waiter comes by, the first person he asks for his order isn't ready; however, the other 9 people are. Thus, the waiter asks the other 9 people for their orders and then comes back to the original guy hoping he'll be ready to order by then. (It's definitely not the case that they'll get a second waiter to wait for the original guy to be ready to order and doing so probably wouldn't save much time anyway). That's how async/await works in many cases (the exception being that some of the Task Parallel library calls, like Thread.Run(...), actually are executing on other threads - in our illustration, bringing in a second waiter - so make sure you check the documentation for which is which).

The case where you'd want multiple waiters is for tasks that are truly "waiter-bound" (i.e. where the waiter would be the primary holdup for the task). For example, if your restaurant has 100 tables it wouldn't be smart to have a single waiter try to service all of them, nor would it be smart to also have the waiter also prepare the food once he takes the orders. In these cases, you'd want to have a separate person to cook the food and several waiters. Eventually you might want multiple cooks too and maybe busboys, etc. This is a case where you'd have multiple threads; generally, the threads would serve specialized roles (e.g. waiters, busboys, cooks, etc.) and would "divide up" work that fit into their particular category (e.g. each waiter would work several tables).

For your particular application, though, even if you do create a new thread to handle each user, there are much better ways of doing what you want than continuously polling for a result using while and Thread.Sleep, such as the ManualResetEvent class, which allows you to block a thread (or group of threads) until a particular event has happened (thus eliminating the need for a polling loop).

EJoshuaS - Stand with Ukraine
  • 11,977
  • 56
  • 49
  • 78