unblocked Sleep() for all Platforms

[Thaddy]

Why sleep(1)? Shouldn't it be sleep(0)?

[rvk]

Why sleep(1)? Shouldn't it be sleep(0)?

Why should it he sleep(0).

With sleep(0) you only relinquish the current time slice. But maybe you want your program to wait a lot longer. Doing sleep(0) each time is waisting time for each cycle.

But it might have been better to use sleep(10) or sleep(50).
It would depend on your usecase for this new non-blocking sleep function.

[KodeZwerg]

Btw GetTickCount64 is a Windows function but is recreated in FPC to be cross platform.

Ahhhh this i did not knew yet, i am very common with Windows Api calls but really didnt knew that FPC reintroduce it for others!!!
Thanks for that information!!!

[KodeZwerg]

Why sleep(1)? Shouldn't it be sleep(0)?

Why should it he sleep(0).

With sleep(0) you only relinquish the current time slice. But maybe you want your program to wait a lot longer. Doing sleep(0) each time is waisting time for each cycle.

But it might have been better to use sleep(10) or sleep(50).
It would depend on your usecase for this new non-blocking sleep function.

I do fully agree, RTL Sleep(50) i also use(if at all)

[PascalDragon]

In Windows i do use this ->

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

1. procedure Sleep(const AMilliSeconds: DWORD);
2. var
3.   Ret: DWORD;
4.   WaitTime: Int64;
5.   Timer: THandle;
6. begin
7.   Timer := CreateWaitableTimer(nil, TRUE, nil);
8.   WaitTime := Round((AMilliSeconds / 1000) * -10000000);
9.   SetWaitableTimer(Timer, WaitTime, 0, nil, nil, FALSE);
10.   repeat
11.     Ret := MsgWaitForMultipleObjects(1, Timer, FALSE, INFINITE, QS_ALLINPUT);
12.     if (Ret <> (WAIT_OBJECT_0+1)) then
13.       Break;
14.     Application.ProcessMessages;
15.   until False;
16.   if (Ret <> WAIT_OBJECT_0) then
17.     CancelWaitableTimer(Timer);
18.   CloseHandle(Timer);
19. end;
20.  

to temporarily suspend the workflow without that my application freeze or i do waste CPU.

Since i do use pure Windows Api calls to achieve that, how can i do the same for other OS's?

You'll have to dig into each OS and widgetset you want to support to get a 1:1 equivalent of this, especially the QS_ALLINPUT. If you're happy with getting interrupted due to received signals (which does likely not contain messages posted to the widgetset's message queue) on *nix systems you can simply use what FPC uses for it's Sleep implementation on *nix (namely fpnanosleep) and handle an error of ESysEINTR accordingly.