Re: [Lazarus] TThread.Synchronize

[Mattias Gaertner via Lazarus]

On Wed, 26 Oct 2016 20:23:11 +0200
Sascha Hestermann via Lazarus  wrote:

> Am 26.10.2016 um 12:02 schrieb LacaK via Lazarus:
> > Btw. when TTimer is executing OnTimer method, which does not finishes
> > until next Interval is elapsed, is again called OnTimer ? Or next
> > OnTimer is performed only when prior OnTimer finished ?  

The next time event is set when the timer event has finished. That's
why it is not an exact interval timer.

 
> Afaik TTimer periodically sends a message to the event queue (at least
> on Windows) and the OnTimer method is called once this message is
> processed. So unless you call ProcessMessages within your OnTimer method
> it won't be called again before it's finished.

Yes.


Mattias
-- 
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
http://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] TThread.Synchronize

[LacaK via Lazarus]

Dňa 26.10.2016 o 11:17 Michael Schnell via Lazarus napísal(a):

On 26.10.2016 07:57, LacaK via Lazarus wrote:

procedure TRefreshFileListThread.Execute;
begin
  while not Terminated do begin
Synchronize(@MyForm.UpdateFileList); // UpdateFileList is method 
which clears listbox and then adds files in given shared folder

Sleep(1);
  end;
This only makes sense if the actual file list generation (all but the 
GUI update) is done in not shown code in the thread before Synchonize 
is called.

no.
thread code is all what you see above.
my intention was use thread only for periodical refresh of list



Otherwise you just could use TTimer.
probably yes. I do not remember why I have used thread for it. May be I 
do not wanted dependency on ExtCtrls ...
Btw. when TTimer is executing OnTimer method, which does not finishes 
until next Interval is elapsed, is again called OnTimer ? Or next 
OnTimer is performed only when prior OnTimer finished ?


-Laco.

--
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
http://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] TThread.Synchronize

[LacaK via Lazarus]

Big Thanks to all. Now I understand what is happening ... probably I wil 
use critical section to block access from thread when code in main 
thread is performed ...

-Laco.




ShowModal() for a modal form will call it.

[...]
I did test in Delphi and Delphi seems also perform synchronize upon
ShowModal

Yes.



Nowhere is it stated or guaranteed that synchronisation cannot happen
in a GUI event
handler.

But cann't happen if nobody calls ProcessMessages or CheckSynchronize
explicitly.
So if user code is executed in event handler then this execution cann't
be interrupted by thread waiting for "synchronization"

Yes.
Unless you call something that does call HandleMessages/ProcessMessages
or CheckSynchronize.

  

Any code at any time can call the GUI message loop. A modal form is
just one instance.

ModalForm is IMO one example but may be alone in LCL ... as there are no
more controls which do same, does not ?

The dialogs like TOpenDialog and ShowMessage call it.
Another example is reading the Clipboard on gtk and retrieving files in
TShellTreeView.


Mattias

--
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
http://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] TThread.Synchronize

[LacaK via Lazarus]

ShowModal() for a modal form will call it.


Ah really?
It happens in my application!


Then that is  your problem.

:-)))



But is it correct behavior ? IMO it is against thread safety, which 
should Synchronize guarantee!


The two issues are completely unrelated. The current behaviour is 
correct.
I did test in Delphi and Delphi seems also perform synchronize upon 
ShowModal




Nowhere is it stated or guaranteed that synchronisation cannot happen 
in a GUI event
handler. 


But cann't happen if nobody calls ProcessMessages or CheckSynchronize 
explicitly.
So if user code is executed in event handler then this execution cann't 
be interrupted by thread waiting for "synchronization"



Any code at any time can call the GUI message loop. A modal form is
just one instance.


ModalForm is IMO one example but may be alone in LCL ... as there are no 
more controls which do same, does not ?

So in my mind it is very specific case, which should be documented.
Of course there can be any user defined control which will do same ...



Your code must be able to deal with this.


Yes, thanks

-Laco.

--
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
http://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] TThread.Synchronize

[Michael Van Canneyt via Lazarus]

On Wed, 26 Oct 2016, LacaK via Lazarus wrote:







Check for Application.ProcessMessages and CheckSynchronize calls. 
These process synchronize queue, if I am not mistaken.


I do not call CheckSynchronize nor ProcessMessages in my application.
So only any LCL component or widget set can call it in background ?


ShowModal() for a modal form will call it.


Ah really?
It happens in my application!


Then that is  your problem.

But is it correct behavior ? IMO it is against thread safety, which 
should Synchronize guarantee!


The two issues are completely unrelated. The current behaviour is correct.

Nowhere is it stated or guaranteed that synchronisation cannot happen in a GUI 
event
handler. Any code at any time can call the GUI message loop. A modal form is
just one instance. Your code must be able to deal with this.

Michael.
--
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
http://lists.lazarus-ide.org/listinfo/lazarus