implementation of daemon thread

[kushal bhattacharya]

hi,
I am trying to run thread in background.My scenario is first i accept value as command line argument to create number of connect client in n number of threads(where n is the value from command line).Then i take user input for publishing message to that connected clients.(this function is also run in n separate threads the connect client threads have stopped by now).the function has infinite while loop where sleep() is implemented and the message is published to console at a certain timeout.sleep is done after the message is published so the execution jumps accross n threads publishing message.The thing i now want is at the same time i want to provide user input to the console .With this architecture i can't really have anything in mind to take user input simultaneously now.How can i do that.Should i use daemon threads? and if so how do i implement that.
Thanks,
Kushal

[Paavo Helde]

The console is shared by the whole process and this creates a lot of
problems when multiple threads try to read it. In my experience the
cleanest solution is to have an extra dedicated thread for console input
(and also output, if you want it to be displayed nicely). This thread
should sit in an infinite loop and wait for messages/commands from other
threads. When any other thread wants to get some input from the user
then it sends a message/command to the console thread, which outputs the
question/prompt, then reads in the user input and sends it back to the
original thread. Then it goes back to waiting in the infinite loop.

If the user wants to give some command while no thread is asking
anything, he should press Ctrl-C. This should be handled in yet another
thread (see SetConsoleCtrlHandler() and/or sigwait()) which communicates
with the console thread via the exact same mechanism.

To make this post on-topic: in C++ one can conveniently use std::deque
(of course, properly mutex-protected) for such inter-thread message queues.

hth
Paavo

[kushal bhattacharya]

i have tried making the console input in different thread but there's some data miscrepencies going on in other words when i ruin different threads using console input one thread works fine but the other thread shows segmentation fault .Could u please tell me what is the real issue behind this ? why am i getting this type of behaviour ?

[Öö Tiib]

The real reason for such misbehavior is that there are number of
programming defects in your code that are probably related to
synchronization of threads.

[kushal bhattacharya]

so,what should i do in this scenario

[Paavo Helde]

On 10.12.2016 8:19, kushal bhattacharya wrote:
> so,what should i do in this scenario

Fix the bugs in the code, obviously. Any time your app crashes, there is
a bug somewhere, and with a probability of at least 99.999% it is a bug
created by yourself.

[kushal bhattacharya]

thanx i was testing the behaviour of threads and accordingly did trial and error and i fixed some of the bugs of the program.THe only thing i am facing is the time to input in the console is less available.I have put a sleep in the console thread but still its somewhat fast (the speed decreased to some extent).What should i implement now in order to have a sober pace between other threads spawned within the console(while loop where console input thread is created) and the console thread

[Paavo Helde]

On 11.12.2016 7:21, kushal bhattacharya wrote:
> thanx i was testing the behaviour of threads and accordingly did trial and error and i fixed some of the bugs of the program.THe only thing i am facing is the time to input in the console is less available.I have put a sleep in the console thread but still its somewhat fast (the speed decreased to some extent).What should i implement now in order to have a sober pace between other threads spawned within the console(while loop where console input thread is created) and the console thread

In a proper multithreaded program there is no place for a simple sleep
as you cannot wake another thread easily from sleep easily when needed,
and also because it is a very inefficient method for thread
synchronization, as you have discovered.

Instead, you should use std::mutex, std::unique_lock and
std::condition_variable classes. All calls to sleep() should be replaced
by calls of std::condition_variable::wait() or its cousins.

hth
Paavo