TThread.Queue vs TThread.Synchronize

classic Classic list List threaded Threaded
41 messages Options
123
Reply | Threaded
Open this post in threaded view
|

TThread.Queue vs TThread.Synchronize

Graeme Geldenhuys-6
Hi,

I've recently seen some posts in Delphi groups that the preferred way is
to use TThread.Queue instead of TThread.Synchronize.

Why is that? What are the benefits?

I've look at FPC trunk and see we now have a Queue() implementation, and
I adjusted a simple multi-threaded GUI example app I had. But I still
don't really understand what is the benefit of Queue vs Synchronise. I
still had to create a "synchronise method" which I pass in to Queue() -
similar to what I did for Synchronize().

Also how is Queue() calls processed? For example to get Synchronize() to
work I had to call CheckSynchronize in my main event loop. Is this also
required for Queue() functionality?

Regards,
  - Graeme -

--
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: TThread.Queue vs TThread.Synchronize

Michael Schnell
On 02/23/2015 11:08 AM, Graeme Geldenhuys wrote:
> Hi,
>
> I've recently seen some posts in Delphi groups that the preferred way is
> to use TThread.Queue instead of TThread.Synchronize.
TThread.Queue just "fires" an Event in the main thread. This means a
"mark" is set that the event handler function is to be started by the
main thread. Same performs this "as soon as possible", meaning that it
is done as soon as the man thread is idle (no previously scheduled
Events ("fired" by threads, GUI, ...) are in the pipe any more.

TThread.Synchronize does exactly the same, only that the thread calling
TThread.Synchronize is frozen after firing the event, and the event
handler is enhanced by code that frees the thread after the user code of
the event handler is finished.

TThread.Queue works very similar to Application.QueueAsyncCall in the LCL

>
> Why is that? What are the benefits?
Obviously TThread.Queue does not hamper the firing thread, while
TThread.Synchronize stalls it for an undefined amount of time.
As a benefit TThread,Synchronize avoids imposing mutual access issues,.

-Michael

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: TThread.Queue vs TThread.Synchronize

Mattias Gaertner
In reply to this post by Graeme Geldenhuys-6
On Mon, 23 Feb 2015 10:08:45 +0000
Graeme Geldenhuys <[hidden email]> wrote:

> Hi,
>
> I've recently seen some posts in Delphi groups that the preferred way is
> to use TThread.Queue instead of TThread.Synchronize.
>
> Why is that? What are the benefits?

Synchronize waits for the main thread.
Queue does not.
Both are executed by the main thread via CheckSynchronize.
Both are useful.

> I've look at FPC trunk and see we now have a Queue() implementation, and
> I adjusted a simple multi-threaded GUI example app I had. But I still
> don't really understand what is the benefit of Queue vs Synchronise. I
> still had to create a "synchronise method" which I pass in to Queue() -
> similar to what I did for Synchronize().
>
> Also how is Queue() calls processed? For example to get Synchronize() to
> work I had to call CheckSynchronize in my main event loop. Is this also
> required for Queue() functionality?

Yes.

Mattias
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: TThread.Queue vs TThread.Synchronize

Michael Schnell
In reply to this post by Graeme Geldenhuys-6
On 02/23/2015 11:08 AM, Graeme Geldenhuys wrote:
>
> I've look at FPC trunk and see we now have a Queue() implementation, and
> I adjusted a simple multi-threaded GUI example app I had. But I still
> don't really understand what is the benefit of Queue vs Synchronise. I
> still had to create a "synchronise method" which I pass in to Queue() -
> similar to what I did for Synchronize().

I once did a testing program that checks the functionality of
TThread.Synchronize, TThread.Queue and Application.QueueAsyncCall (and
some other stuff) with and without attaching a GUI. Let me know if you
want to have it.

>
> Also how is Queue() calls processed? For example to get Synchronize() to
> work I had to call CheckSynchronize in my main event loop. Is this also
> required for Queue() functionality?

In the FPC RTL, "CheckSynchronize" in fact polls the Event Queue, and
performs the callbacks of the Events (Queued elements) that are push
upon this queue e.g. by TThread.Synchronize and TThread.Queue.

IMHO the legacy name "CheckSynchronize" is rather misleading.

Due to the "private" nature of the queue mechanism in the FPC RTL,
Application.QueueAsyncCall in the RTL works completely different than
TThread.Queue, (using a different Event (aka "message") queue that is
unknown to the fpc RTL but implemented (or attached to) by the LCL.

I once did a "non-GUI TApplication" for the LCL that does not attach to
any external GUI. It can't be "officially" released right now, as
Application.QueueAsyncCall needs to push events in the said queue. This
can't be done "directly", as the stuff is private in the RTL, and hence
I need to wait until the next version of the RTL provides TThread.Queue
that is usable for this purpose.

I once wrote a documentation on how the event queue in the fpc RTL
works, but failed with the attempt to have it included in the fpc help.

-Michael
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: TThread.Queue vs TThread.Synchronize

Graeme Geldenhuys-6
In reply to this post by Michael Schnell
On 2015-02-23 10:52, Michael Schnell wrote:
> TThread.Queue works very similar to Application.QueueAsyncCall in the LCL

I don't use LCL, so I'm not familiar with all its features.


> Obviously TThread.Queue does not hamper the firing thread, while
> TThread.Synchronize stalls it for an undefined amount of time.

Ah ok, so Synchronize() is a blocking call and Queue() isn't. That would
explain why some prefer Queue().


Regards,
  - Graeme -

--
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: TThread.Queue vs TThread.Synchronize

Graeme Geldenhuys-6
In reply to this post by Mattias Gaertner
On 2015-02-23 10:56, Mattias Gaertner wrote:
> Synchronize waits for the main thread.
> Queue does not.
> Both are executed by the main thread via CheckSynchronize.
> Both are useful.


Many thanks for that info. It makes sense now.


Regards,
  - Graeme -

--
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: TThread.Queue vs TThread.Synchronize

Marcos Douglas B. Santos
On Mon, Feb 23, 2015 at 2:44 PM, Graeme Geldenhuys
<[hidden email]> wrote:
> On 2015-02-23 10:56, Mattias Gaertner wrote:
>> Synchronize waits for the main thread.
>> Queue does not.
>> Both are executed by the main thread via CheckSynchronize.
>> Both are useful.
>
>
> Many thanks for that info. It makes sense now.

+1
Thanks too.

Marcos Douglas
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: TThread.Queue vs TThread.Synchronize

Graeme Geldenhuys-6
In reply to this post by Michael Schnell
On 2015-02-23 11:25, Michael Schnell wrote:
> Let me know if you want to have it.

Yeah please. You can email it to this email address.


> I once wrote a documentation on how the event queue in the fpc RTL
> works, but failed with the attempt to have it included in the fpc help.

Why not add it to the Wiki then, so your efforts would not have been wasted.


Regards,
  - Graeme -

--
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: TThread.Queue vs TThread.Synchronize

Graeme Geldenhuys-6
In reply to this post by Graeme Geldenhuys-6
Continuing on the TThread.Queue subject - is there any way to pass
parameters (or record structure with basic types) to the Queue() call?

That would be super useful instead of putting thread locking on
variables (for example, reading a progress value to update a GUI
progress bar).

I understand that anonymous methods (something I again don't know much
about) take a snapshot of local variables. So that could possibly be
used with TThread.Queue() to send variable (simple data types)
information? Please correct my if I am wrong - like I said, I don't
really know anonymous methods or their real usage.

Regards,
  - Graeme -

--
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: TThread.Queue vs TThread.Synchronize

Sven Barth-2
On 23.02.2015 18:58, Graeme Geldenhuys wrote:
> Continuing on the TThread.Queue subject - is there any way to pass
> parameters (or record structure with basic types) to the Queue() call?
>
> That would be super useful instead of putting thread locking on
> variables (for example, reading a progress value to update a GUI
> progress bar).

Currently the only method is to use fields that belong to the TThread
instance.

> I understand that anonymous methods (something I again don't know much
> about) take a snapshot of local variables. So that could possibly be
> used with TThread.Queue() to send variable (simple data types)
> information? Please correct my if I am wrong - like I said, I don't
> really know anonymous methods or their real usage.

In Delphi both TThread.Queue() and TThread.Synchronize() have overloads
to accept anonymous functions. It would then work like this:

=== code begin ===

type
   TPrintEvent = procedure(const aMsg: String) of object;

   TMyThread = class(TThread)
   private
     fOnPrint: TPrintEvent;
   protected
     procedure Execute; override;
     property OnPrint: TPrintEvent read fOnPrint write fOnPrint;
   end;

procedure TMyThread.Execute;
var
   s: String;
begin
   s := 'Hello World';
   Queue(procedure
     begin
       fOnPrint(s);
     end);
end;

=== code end ===

In this example both "fOnPrint" and "s" would be captured by the
anonymous functions and will be available even after the thread has
terminated.

For FPC modes and those people that dislike the syntax of anonymous
functions (and yes, I can understand those people ;) ) I hope that we'll
get the following variation to work as well:

=== code begin ===

procedure TMyThread.Execute;
var
   s: String;

   procedure SyncOnPrint;
   begin
     fOnPrint(s);
   end;

begin
   s := 'Hello World';
   Queue(@SyncOnPrint);
end;

=== code end ===

Regards,
Sven
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: TThread.Queue vs TThread.Synchronize

silvioprog
On Mon, Feb 23, 2015 at 3:23 PM, Sven Barth <[hidden email]> wrote:
[...]=== code begin ===

procedure TMyThread.Execute;
var
  s: String;

  procedure SyncOnPrint;
  begin
    fOnPrint(s);
  end;

begin
  s := 'Hello World';
  Queue(@SyncOnPrint);
end;

=== code end ===

How to compile it?:

Error: Incompatible type for arg no. 1: Got "<address of procedure is nested;Register>", expected "<procedure variable type of procedure of object;Register>".

--
Silvio Clécio
My public projects - github.com/silvioprog

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: TThread.Queue vs TThread.Synchronize

philippe sylvain levi

what you want to do makes sense? I don't think so. Thread code "may not" access stack values of calling code ...



De: [hidden email] <[hidden email]> em nome de silvioprog <[hidden email]>
Enviado: segunda-feira, 23 de fevereiro de 2015 15:32
Para: FPC-Pascal users discussions
Assunto: Re: [fpc-pascal] TThread.Queue vs TThread.Synchronize
 
On Mon, Feb 23, 2015 at 3:23 PM, Sven Barth <[hidden email]> wrote:
[...]=== code begin ===

procedure TMyThread.Execute;
var
  s: String;

  procedure SyncOnPrint;
  begin
    fOnPrint(s);
  end;

begin
  s := 'Hello World';
  Queue(@SyncOnPrint);
end;

=== code end ===

How to compile it?:

Error: Incompatible type for arg no. 1: Got "<address of procedure is nested;Register>", expected "<procedure variable type of procedure of object;Register>".

--
Silvio Clécio
My public projects - github.com/silvioprog

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: TThread.Queue vs TThread.Synchronize

philippe sylvain levi
In reply to this post by Sven Barth-2
I "thought" it was not possible to use local procedure address as parameter like in queue( @SyncOnPrint);
as Clecio showed ...

________________________________________
De: [hidden email] <[hidden email]> em nome de Sven Barth <[hidden email]>
Enviado: segunda-feira, 23 de fevereiro de 2015 15:23
Para: [hidden email]
Assunto: Re: [fpc-pascal] TThread.Queue vs TThread.Synchronize

On 23.02.2015 18:58, Graeme Geldenhuys wrote:
> Continuing on the TThread.Queue subject - is there any way to pass
> parameters (or record structure with basic types) to the Queue() call?
>
> That would be super useful instead of putting thread locking on
> variables (for example, reading a progress value to update a GUI
> progress bar).

Currently the only method is to use fields that belong to the TThread
instance.

> I understand that anonymous methods (something I again don't know much
> about) take a snapshot of local variables. So that could possibly be
> used with TThread.Queue() to send variable (simple data types)
> information? Please correct my if I am wrong - like I said, I don't
> really know anonymous methods or their real usage.

In Delphi both TThread.Queue() and TThread.Synchronize() have overloads
to accept anonymous functions. It would then work like this:

=== code begin ===

type
   TPrintEvent = procedure(const aMsg: String) of object;

   TMyThread = class(TThread)
   private
     fOnPrint: TPrintEvent;
   protected
     procedure Execute; override;
     property OnPrint: TPrintEvent read fOnPrint write fOnPrint;
   end;

procedure TMyThread.Execute;
var
   s: String;
begin
   s := 'Hello World';
   Queue(procedure
     begin
       fOnPrint(s);
     end);
end;

=== code end ===

In this example both "fOnPrint" and "s" would be captured by the
anonymous functions and will be available even after the thread has
terminated.

For FPC modes and those people that dislike the syntax of anonymous
functions (and yes, I can understand those people ;) ) I hope that we'll
get the following variation to work as well:

=== code begin ===

procedure TMyThread.Execute;
var
   s: String;

   procedure SyncOnPrint;
   begin
     fOnPrint(s);
   end;

begin
   s := 'Hello World';
   Queue(@SyncOnPrint);
end;

=== code end ===

Regards,
Sven
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: TThread.Queue vs TThread.Synchronize

Sven Barth-2
In reply to this post by silvioprog
On 23.02.2015 19:32, silvioprog wrote:

> On Mon, Feb 23, 2015 at 3:23 PM, Sven Barth <[hidden email]
> <mailto:[hidden email]>> wrote:
> [...]=== code begin ===
>
>
>     procedure TMyThread.Execute;
>     var
>        s: String;
>
>        procedure SyncOnPrint;
>        begin
>          fOnPrint(s);
>        end;
>
>     begin
>        s := 'Hello World';
>        Queue(@SyncOnPrint);
>     end;
>
>     === code end ===
>
>
> How to compile it?:
>
> Error: Incompatible type for arg no. 1: Got "<address of procedure is
> nested;Register>", expected "<procedure variable type of procedure of
> object;Register>".

Did you even read this part? And especially the tense it's written in?

>
> For FPC modes and those people that dislike the syntax of anonymous functions (and yes, I can understand those people ) I hope that we'll get the following variation to work as well:

Regards,
Sven

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: TThread.Queue vs TThread.Synchronize

Sven Barth-2
In reply to this post by philippe sylvain levi
On 23.02.2015 19:41, Philippe Lévi wrote:
> I "thought" it was not possible to use local procedure address as parameter like in queue( @SyncOnPrint);
> as Clecio showed ...

Please read the following part of my message again:

>
> For FPC modes and those people that dislike the syntax of anonymous functions (and yes, I can understand those people ) I hope that we'll get the following variation to work as well:

Regards,
Sven

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: TThread.Queue vs TThread.Synchronize

philippe sylvain levi
may be I do not catch it well ... problem with my english understan ... may be. "we'll get" ... you mean some day it should be possible to program it? .... correct?

you mean it will be possible to use a pointer to local function in a call?

or I misunderstand ...

________________________________________
De: [hidden email] <[hidden email]> em nome de Sven Barth <[hidden email]>
Enviado: segunda-feira, 23 de fevereiro de 2015 16:17
Para: [hidden email]
Assunto: Re: [fpc-pascal] TThread.Queue vs TThread.Synchronize

On 23.02.2015 19:41, Philippe Lévi wrote:
> I "thought" it was not possible to use local procedure address as parameter like in queue( @SyncOnPrint);
> as Clecio showed ...

Please read the following part of my message again:

>
> For FPC modes and those people that dislike the syntax of anonymous functions (and yes, I can understand those people ) I hope that we'll get the following variation to work as well:

Regards,
Sven

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: TThread.Queue vs TThread.Synchronize

silvioprog
On Mon, Feb 23, 2015 at 4:24 PM, Philippe Lévi <[hidden email]> wrote:
may be I do not catch it well ... problem with my english understan ... may be. "we'll get" ... you mean some day it should be possible to program it? .... correct?

you mean it will be possible to use a pointer to local function in a call?

or I misunderstand ...

________________________________________
De: [hidden email] <[hidden email]> em nome de Sven Barth <[hidden email]>
Enviado: segunda-feira, 23 de fevereiro de 2015 16:17
Para: [hidden email]
Assunto: Re: [fpc-pascal] TThread.Queue vs TThread.Synchronize

On 23.02.2015 19:41, Philippe Lévi wrote:
> I "thought" it was not possible to use local procedure address as parameter like in queue( @SyncOnPrint);
> as Clecio showed ...

Please read the following part of my message again:

>
> For FPC modes and those people that dislike the syntax of anonymous functions (and yes, I can understand those people ) I hope that we'll get the following variation to work as well:

Regards,
Sven

Oops, sorry. Just confusion on translation.

you mean it will be possible to use a pointer to local function in a call? ²

(some switch to enable this feature?)
 
--
Silvio Clécio
My public projects - github.com/silvioprog

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: TThread.Queue vs TThread.Synchronize

Sven Barth-2
In reply to this post by philippe sylvain levi
On 23.02.2015 20:24, Philippe Lévi wrote:
> may be I do not catch it well ... problem with my english understan ... may be. "we'll get" ... you mean some day it should be possible to program it? .... correct?
>
> you mean it will be possible to use a pointer to local function in a call?
>
> or I misunderstand ...

Yes, it's future tense. And also there's the "I hope".

Also under certain circumstances you can already pass local procedures
to other functions (requires 2.7.1 or newer):

=== code begin ===

program tnested;

{$mode objfpc}{$H+}
{$modeswitch nestedprocvars}

type
   TProc = procedure is nested;

procedure WriteStr(const aMsg: String);
begin
   Writeln(aMsg);
end;

procedure AnotherTest(aProc: TProc);
begin
   aProc();
end;

procedure Test;
var
   s: String;

   procedure PrintStr;
   begin
     Writeln(s);
   end;

begin
   s := 'Hello World';
   AnotherTest(@PrintStr);
end;

begin
   Test;
end.

=== code end ===

There is however an important difference to anonymous functions: If you
- in this example - leave the scope of "Test" the variable "s" will no
longer be valid. An anonymous function on the other hand will capture
that variable and will allow the use of the procedure variable even
later on.

E.g. the following would work with anonymous methods, but not with
nested procedure variables:

=== code begin ===

type
   TStringProc = reference to procedure; // this will work
   //TStringProc = procedure is nested; // this will not work

function Test: TStringProc;
var
   s: String;

   procedure PrintStr;
   begin
     Writeln(s);
   end;

begin
   s := 'Hello World';
   Result := @PrintStr;
end;

=== code end ===

Of course the above only applies if we should managed to get local
procedures supported for anonymous function variables...

Regards,
Sven
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: TThread.Queue vs TThread.Synchronize

Sven Barth-2
In reply to this post by silvioprog
On 23.02.2015 20:29, silvioprog wrote:

> On Mon, Feb 23, 2015 at 4:24 PM, Philippe Lévi <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     may be I do not catch it well ... problem with my english understan
>     ... may be. "we'll get" ... you mean some day it should be possible
>     to program it? .... correct?
>
>     you mean it will be possible to use a pointer to local function in a
>     call?
>
>     or I misunderstand ...
>
>     ________________________________________
>     De: [hidden email]
>     <mailto:[hidden email]>
>     <[hidden email]
>     <mailto:[hidden email]>> em nome de Sven
>     Barth <[hidden email] <mailto:[hidden email]>>
>     Enviado: segunda-feira, 23 de fevereiro de 2015 16:17
>     Para: [hidden email]
>     <mailto:[hidden email]>
>     Assunto: Re: [fpc-pascal] TThread.Queue vs TThread.Synchronize
>
>     On 23.02.2015 19:41, Philippe Lévi wrote:
>      > I "thought" it was not possible to use local procedure address as
>     parameter like in queue( @SyncOnPrint);
>      > as Clecio showed ...
>
>     Please read the following part of my message again:
>
>      >
>      > For FPC modes and those people that dislike the syntax of
>     anonymous functions (and yes, I can understand those people ) I hope
>     that we'll get the following variation to work as well:
>
>     Regards,
>     Sven
>
>
> Oops, sorry. Just confusion on translation.
>
> you mean it will be possible to use a pointer to local function in a call? ²
>
> (some switch to enable this feature?)

See the mail I just sent to the list. In short: yes, but not exactly as
I presented in my example with TThread.Queue().

Regards,
Sven
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: TThread.Queue vs TThread.Synchronize

silvioprog
On Mon, Feb 23, 2015 at 4:39 PM, Sven Barth <[hidden email]> wrote:
On 23.02.2015 20:29, silvioprog wrote:
On Mon, Feb 23, 2015 at 4:24 PM, Philippe Lévi <[hidden email]
<mailto:[hidden email]>> wrote:

    may be I do not catch it well ... problem with my english understan
    ... may be. "we'll get" ... you mean some day it should be possible
    to program it? .... correct?

    you mean it will be possible to use a pointer to local function in a
    call?

    or I misunderstand ...

    ________________________________________
    De: [hidden email]
    <mailto:[hidden email]>
    <[hidden email]
    <mailto:[hidden email]>> em nome de Sven
    Barth <[hidden email] <mailto:[hidden email]>>
    Enviado: segunda-feira, 23 de fevereiro de 2015 16:17
    Para: [hidden email]
    <mailto:[hidden email]>
    Assunto: Re: [fpc-pascal] TThread.Queue vs TThread.Synchronize

    On 23.02.2015 19:41, Philippe Lévi wrote:
     > I "thought" it was not possible to use local procedure address as
    parameter like in queue( @SyncOnPrint);
     > as Clecio showed ...

    Please read the following part of my message again:

     >
     > For FPC modes and those people that dislike the syntax of
    anonymous functions (and yes, I can understand those people ) I hope
    that we'll get the following variation to work as well:

    Regards,
    Sven


Oops, sorry. Just confusion on translation.

you mean it will be possible to use a pointer to local function in a call? ²

(some switch to enable this feature?)

See the mail I just sent to the list. In short: yes, but not exactly as I presented in my example with TThread.Queue().

I saw. It is very nice. Thank you! =)
 
--
Silvio Clécio
My public projects - github.com/silvioprog

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
123