Recent

Author Topic: TTimer is not safe  (Read 5519 times)

AlexTP

  • Hero Member
  • *****
  • Posts: 2384
    • UVviewsoft
TTimer is not safe
« on: January 20, 2019, 08:48:46 am »
I've seen few things in CudaText, it leads me to conclusion that TTimer
is broken on Linux gtk2 x64 (Ubuntu 18.04). fpc 3.0.4.

- caret stops blinking (sometimes, after Alt+Tab)
- syntax parsing cannot end (sometimes, works by timer too)
- inactive buttons, still hilite after cursor moved out of window (have timer workaround which works most of the time)
« Last Edit: January 20, 2019, 11:49:57 am by Alextp »

Thaddy

  • Hero Member
  • *****
  • Posts: 14199
  • Probably until I exterminate Putin.
Re: TTimer is not safe
« Reply #1 on: January 20, 2019, 10:56:02 am »
We had a similar issue at my old job. After TThread.Queue was introduced we changed our design to a threaded model where each threads loop iteration was closed with a sleep(0) which means relinquish time slice.  This gave an unexpected performance gain of over ~20% . The issue is not GTK specific: it can also happen on Windows under heavy load.
You need to test with a slower Intel type windows machine to verify this (some Celeron notebooks and AMD E series notebooks were used to reproduce our issue by our testers).
It may well be that a similar approach will also work for CudaText.
« Last Edit: January 20, 2019, 11:02:07 am by Thaddy »
Specialize a type, not a var.

AlexTP

  • Hero Member
  • *****
  • Posts: 2384
    • UVviewsoft
Re: TTimer is not safe
« Reply #2 on: January 20, 2019, 11:48:12 am »
hmm, I cannot get the idea: timer was broken after TThread change or timer was fixed after TThread change?
how can I fix/workaround it?
I'm using fpc 3.0.4.
« Last Edit: January 20, 2019, 11:50:19 am by Alextp »

Thaddy

  • Hero Member
  • *****
  • Posts: 14199
  • Probably until I exterminate Putin.
Re: TTimer is not safe
« Reply #3 on: January 20, 2019, 01:35:10 pm »
The idea is to *not* use a TTimer but queue any pending updates and sleep(0) after every loop iteration.
A timer is really not the best solution for CudoText. A Sleep(0) will execute one of the pending updates in the main thread, which is a better model.
Specialize a type, not a var.

440bx

  • Hero Member
  • *****
  • Posts: 3944
Re: TTimer is not safe
« Reply #4 on: January 20, 2019, 01:42:01 pm »
how can I fix/workaround it?
A workaround depends on knowing why it is not working.  However... 

You could try creating your own thread to post Timer messages to the application's message pump.  If the problem persists (which it very well might) then you could have the thread itself perform the actions needed instead of posting a message, for instance, call the procedure/function/method that would have been executed if timer messages were being processed correctly.

HTH.
(FPC v3.0.4 and Lazarus 1.8.2) or (FPC v3.2.2 and Lazarus v3.2) on Windows 7 SP1 64bit.

Thaddy

  • Hero Member
  • *****
  • Posts: 14199
  • Probably until I exterminate Putin.
Re: TTimer is not safe
« Reply #5 on: January 20, 2019, 01:55:10 pm »
You could try creating your own thread to post Timer messages to the application's message pump.
No, that has the same limitation. A TTimer is limited and not precise enough to rely on with many tasks pending, because the rest of the code would possibly block.
But the rest what you wrote is basically what you do when you use the queue feature of a thread. That is a correct conclusion by you.
Since the feature is not very well documented yet - not even for Delphi !- , I will see if I can come up with a readable example.

My point is that CudaText does not need a timer to schedule those tasks. It just needs to schedule.....with a low enough resolution...
« Last Edit: January 20, 2019, 02:01:39 pm by Thaddy »
Specialize a type, not a var.

440bx

  • Hero Member
  • *****
  • Posts: 3944
Re: TTimer is not safe
« Reply #6 on: January 20, 2019, 02:09:00 pm »
No, that has the same limitation.
Not quite.  One of the reasons I did occasionally implement it is because, in Windows, timer messages are very low priority and, depending on the application, that can get in the way of timely updates.  Using a thread is more responsive than using timer messages or callbacks based on them.

The downside is, it's more work than relying on Windows (in my case) to simply generate the message(s) or executing the callbacks.

I cannot say if it would work for what @Alextp wants to do since I am not familiar with CudaText.  It's up to him to evaluate the idea/method and determine if it would solve the problem he is experiencing.


(FPC v3.0.4 and Lazarus 1.8.2) or (FPC v3.2.2 and Lazarus v3.2) on Windows 7 SP1 64bit.

AlexTP

  • Hero Member
  • *****
  • Posts: 2384
    • UVviewsoft
Re: TTimer is not safe
« Reply #7 on: January 20, 2019, 02:19:19 pm »
Quote
My point is that CudaText does not need a timer to schedule those tasks. It just needs to schedule.....
I don't know how to replace timer with your method (don't know how to write threads + app has many timers: for caret, for button cursor watch...)

engkin

  • Hero Member
  • *****
  • Posts: 3112
Re: TTimer is not safe
« Reply #8 on: January 20, 2019, 02:22:42 pm »
Probably there is a problem in your code. A good explanation and an easy workaround are in this SO thread:
https://stackoverflow.com/questions/11957954/ttimer-not-firing

AlexTP

  • Hero Member
  • *****
  • Posts: 2384
    • UVviewsoft
Re: TTimer is not safe
« Reply #9 on: January 20, 2019, 02:38:30 pm »
Pls a hint, will fpTimer unit help me (if I replace TTimer to this fpTimer)?

engkin

  • Hero Member
  • *****
  • Posts: 3112
Re: TTimer is not safe
« Reply #10 on: January 20, 2019, 03:05:32 pm »
The default driver uses threads, it should work.

AlexTP

  • Hero Member
  • *****
  • Posts: 2384
    • UVviewsoft
Re: TTimer is not safe
« Reply #11 on: January 30, 2019, 11:17:53 am »
New seeing of this: I see that replacement of TTimer to TfpTimer dont help (sometimes caret still stops).
So seems TTimer is okay.

marcov

  • Administrator
  • Hero Member
  • *
  • Posts: 11383
  • FPC developer.
Re: TTimer is not safe
« Reply #12 on: January 30, 2019, 02:40:27 pm »
Empty the handler method of your ttimer but leave it in, do the problems go away? If so, your timer routine simply is too heavy and eats up to much time.

AlexTP

  • Hero Member
  • *****
  • Posts: 2384
    • UVviewsoft
Re: TTimer is not safe
« Reply #13 on: April 24, 2019, 09:49:13 pm »
Sorry for noise. Now i think TTimer is safe - i just see some issue in my app and now I think the reason is not timer.
https://github.com/Alexey-T/CudaText/issues/1733

 

TinyPortal © 2005-2018