Question : Threaded or async service

Hello,

I need little advise in what path of making programm to choose. I was asking
about this some time ago, but now i have more clear vision of this. App is service, that wait for user logon and starts my other app. It also watches to make my app always running. And ofcourse it do this per user that  is logon. So, when user is loged on and he switch to another user then new user have new instance of programm, and previous one have still his app  running.

So, i have functionality to listen when user logon(ISensLogon). I don't know is this realy needed. Becouse i always can watch is process running in some time intervals by making mutex.

Second functionality is to watch is process running by making mutex and wait for it. (In future i make some additional mechanisms, like IPC).

I have to solutions:

1. asynchronous -
I have made simple class to help me handle windows kernel objects (event, mutex). With it,i can add event so class can wait for it, and when event occure it fire function that is binded to this event in it inicialization .

So my idea is 'Add' event that watch for user logon. When event occur, fired function 'Add' new event that wait for mutex. And when this event occur its start process.

LogonEvent->SetCommand(AddMutexEventToEventListener);
EventListener->Add(LogonEvent);


2. threaded -

In main thread, i simply wait for user logon. Next, when user logon i make new thread that run process and watch for mutex.

I have great desire to choose asynch method becouse it seems to me to be ambitious. But it hardest to code, and code will be hardest to maintenance i think. Threaded solution is hmm cleaner i think.

Could someone give me adivse. Maybe i omitt something important?

Answer : Threaded or async service

The first pattern that you mentioned actually has a name. It's called the "Reactor" pattern, which transforms a select/wait polling based events monitoring into event driven callbacks (I wonder if thats why its called reactor). The reactor (main components) does all the dirty pollling job and you can simply tell it to fire an event when something happens. http://en.wikipedia.org/wiki/Reactor_pattern

Coming back to the question of which is more important, well it looks like you will alwaysd need a worker thread, be that for the reactor or the process monitor thread (unless the reactor is itself using event driven API). If that is the case then the benefit of reactor are more obvious if you have many many events to watch at the same time, like say in your case if you have to monitor dozens of processes/mutexes then a reactor saves you the cost of a thread per monitor.

On the other hand, if its just a matter of a single worker thread then why add complexity when you can easily manage things with a monitor thread? It's sure is ambitious and tempting to go with sophisticated designs (especially when you have arrived at one yourself); I can understand the urge :) but mind it, reliability, ease of use and maintenance are more important than fancy design. After all, your user doesn't care whethers its reactor based design or not.

I suggest that you post further details, especially with respect to scalabity prospects. Like, how many objects can you be watching at the same time (max), how many processes etc.

Hope that helps ...