Sleep forever

[jollytall]

I have a main program that starts a number of threads and they do their own job and they never return (various server activities). As they are from various libraries, I cannot (and do not want to) make any of them the main program. The main program only waits forever and can actually be stopped in a controlled manner through system interrupts (what the main program handles correctly and stops the threads as well).
Now I have

Code: Pascal  [Select][+][-]

1. while true
2.   sleep(10000);

Actually I could put any high number in the sleep, does not matter, 10s just seems long enough not to use the CPU and still a "human" value.
Just for my taste it is still ugly. I would prefer an instruction like "Suspend".
(Yes, I could put my loop in a procedure called suspend, but it would still be the same.)
Isn't there any low level instruction that stops a thread (the main thread!) without exit?

[KodeZwerg]

When it is a GUI type of main application that starts your threads, you actually need to do nothing, beside starting threads and waiting (idle) for messages.

[marcov]

Note that not reacting to windows messages might bring up "DrWatson" "application is not responding, terminate?" messages.

[jollytall]

Thanks, but it is not Windows GUI. This is a Linux Daemon.

[dbannon]

Hmm, not exactly what you are asking for but I do something like this -

Code: Pascal  [Select][+][-]

1. var ExitNow : boolean = false;
2. ....
3. procedure SignalRec(sig : cint);cdecl;
4. begin
5.     writeln('----- Received SigTerm Signal, will exit shortly -----');
6.     ExitNow := True;
7. end;
8.  
9. .....
10. Someloop begin
11.             if ExitNow then begin                           // trigger by SIGTERM, default for kill command
12.                 // do some tiding up
13.                 terminate;                                
14.                 exit;
15.             end;
16.             sleep(100);
17. end;

In your case, you may not need do that tiding up but it does justify the endless loop.

Davo

[MarkMLl]

In your case, you may not need do that tiding up but it does justify the endless loop.

Although that would still benefit from a sleep in the loop.

As a word of warning, I found myself in a position where I could benefit from signal handling to forcibly abort a background thread, but as the code began to get more complex it turned out to be more trouble than it was worth:

Code: Pascal  [Select][+][-]

1. (* I was initially using                                                        *)
2. (*                                                                              *)
3. (*    PThread_kill(Handle, SIGHUP);      Anything stronger than HUP here        *)
4. (*    WaitFor                            would affect the entire process.       *)
5. (*                                                                              *)
6. (* here, but the kill caused major problems in a program which was also hooking *)
7. (* HUP and the WaitFor was just... well, it didn't work once I moved away from  *)
8. (* using HUP for non-obvious reasons.                                           *)
9.  

So from my POV, there's nothing wrong with making sure that syscalls always time out, then checking a termination flag.

MarkMLl

[440bx]

Just for my taste it is still ugly. I would prefer an instruction like "Suspend".

In Windows there is SuspendThread which would solve the problem you've described, isn't there a "suspend thread" service/function in Linux you can use to accomplish the same ?

[cdbc]

Hi

isn't there a "suspend thread" service/function in Linux you can use to accomplish the same ?

Wouldn't it be possible to use an event?
IIRC TRTLEvent.Waitfor suspends the thread... (but then again I can't remember worth of sh*t) 
Regards Benny

[jollytall]

@dbannon
You actually made some meaning for the loop, but I think this is an even worse solution than the one I have. You use a 100ms Sleep (a sleep I wanted to avoid at the first place) and if the flag is set, within 100ms it is noticed and acted on in the main loop. It means that your process must be running every 100ms and You cannot make the sleep much longer, because then the signal is handled with a long delay. Not a big deal, to run the CPU for few clock cycles every 100ms, but if you do the tiding up directly in the SignalRec, then it is done immediately (not somewhere within the length of the sleep) and so the sleep can be much-much longer.

@MarkMLI
I don't really understand how your solution worked (and what was wrong in it).

@440bx
If I can trust SO, it is not implemented in Linux: https://stackoverflow.com/questions/11468333/linux-threads-suspend-resume
Also, IIRC in Windows that was for a thread other than the main program. I think the main program cannot stop itself.

In the meantime, I was also thinking another solution, but in this form, it does not work:

Code: Pascal  [Select][+][-]

1. var
2.   Access : TRTLCriticalSection;
3. begin
4. InitCriticalSection(Access);
5. EnterCriticalSection(Access);
6. EnterCriticalSection(Access);
7. writeln('Finished');
8. end.
9.  

I thought that entering a critical section checks if that semaphore is already blocked, but apparently (as it is correctly written in the manual as well) it checks if that is already blocked BY ANOTHER thread. I probably still could use this trick, first entering a critical section in a sub-thread (and never leaving it) and then try to enter it in the main program as well. This would have the problem though that if for whatever reason the sub-thread is slow, the main program might get there first and exit. With some more checks I can still solve this.
Can it be a working and efficient solution?

[Mr.Madguy]

Two possible solutions. Simple one - use message loop. Thread is suspended, when it waits for next message. That's why GUI apps don't consume CPU time, when they're inactive. Even non-GUI application can create "invisible" window to process messages. As I know, Application.Handle - is exactly such invisible window. Console applications also have similar message loop.

A little bit harder solution - using sync objects and waiting for them to be released. Simple example: TThread.WaitFor.

[jollytall]

Wouldn't it be possible to use an event?

I tried two more tricks. None of them works, but I do not know why.

Code: Pascal  [Select][+][-]

1. var
2.   e : tEventObject;
3. begin
4. RTLEventWaitFor(RTLEventCreate);
5. e:=tEventObject.Create(nil, false, true,'foo');
6. e.WaitFor(INFINITE);
7.  

The RTLEventWaitFor should be waiting forever, since noone sets that locally created event (noone can even know about it, as it is not even stored in a variable). Still it us on.
The second is similar, but there I cannot create the event object, it gives an error message.

[cdbc]

Hi
I have an event-unit that can suspend your mainthread, BUT you can only wake it up from another thread....!
I dunno... Let me know if you wanna try 
Regards Benny

[440bx]

Also, IIRC in Windows that was for a thread other than the main program. I think the main program cannot stop itself.

Just for "completeness", there really isn't anything special about the first thread in Windows which is usually thought of as the "main thread".  The only reason suspending that thread may cause problems is if that thread, as is usually the case, it the thread responsible for pumping messages.

IOW, it is possible and doable without any adverse side effects to suspend the "main program"'s thread without causing any problems provided the application is properly designed.

In yet other words, there is _nothing_ magical about the first thread started in Windows.  Windows does NOT care one way or the other _when_ a thread was created.  It does care about what it does, e.g, pump messages.

HTH.

[Mr.Madguy]

I usually use SyncObjs unit and classes like TCriticalSection and TEvent to sync my threads. Everything seems to work properly.

[Thaddy]

The easy way is  to set/get the TThread.Suspended property, which is cross platform.