Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / fpc-devel / 2014-08

Extension request to TThread extensions

5 messages · 2 people ·

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

Michael Schnell

I found that my intent to do an "active" extension (or variant) of the Lazarus "NoGUI" Widget Type (aka "Interface") is not possible (to be implemented in an IMHO sensible way) using the released version of the FPC RTL, but is rather easy when using the "TThread extensions" provided by the svn version.That is why I will hold off until the next official fpc release.

A (minor) problem is, that "TThread.Queue", which is the entry to the Thread Queue handling I need to use, is done in perfectly Delphi compatible way in that it does not queue the function call but simply performs a call to it when the calling is done from the main thread. While I don't think that this really makes sense, it obviously should stay in place for Delphi compatibility.

Now, "Application.QueueAsnycCall" should be provided in a way that is perfectly compatible to other Lazarus Widget types. And in Lazarus, "Application.QueueAsnycCall" other than "TThread.Queue" always queues the call, even when called from the main thread. Hence using TThread.Queue to implement Application.QueueAsnycCall would introduce a (supposedly very seldom relevant) incompatibility.

This could be helped by creating another TThread procedure for this purpose.

Would a patch for such a thing have a chance to be accepted ?

Thanks,
-Michael

Reply by email

Michael Van Canneyt
to Michael Schnell
Michael Schnell wrote 12 lines
I found that my intent to do an "active" extension (or variant) of the Lazarus "NoGUI" Widget Type (aka "Interface") is not possible (to be implemented in an IMHO sensible way) using the released version of the FPC RTL, but is rather easy when using the "TThread extensions" provided by the svn version.That is why I will hold off until the next official fpc release. A (minor) problem is, that "TThread.Queue", which is the entry to the Thread Queue handling I need to use, is done in perfectly Delphi compatible way in that it does not queue the function call but simply performs a call to it when the calling is done from the main thread. While I don't think that this really makes sense, it obviously should stay in place for Delphi compatibility. Now, "Application.QueueAsnycCall" should be provided in a way that is perfectly compatible to other Lazarus Widget types. And in Lazarus, "Application.QueueAsnycCall" other than "TThread.Queue" always queues the call, even when called from the main thread. Hence using TThread.Queue to implement Application.QueueAsnycCall would introduce a (supposedly very seldom relevant) incompatibility. This could be helped by creating another TThread procedure for this purpose. Would a patch for such a thing have a chance to be accepted ?

There is no need for a patch.

You can perfectly work around this by implementing Application.QueueAsnycCall so that it creates a thread which does the call to TThread.Queue.

Michael.

Reply by email

Michael Schnell
to Michael Van Canneyt
Michael Van Canneyt wrote
You can perfectly work around this by implementing Application.QueueAsnycCall so that it creates a thread which does the call to TThread.Queue.

Do you mean that for an implementation of "Application.QueueAsyncCall" I should
- Check if we are in the Main thread
- if yes create a Dummy TThread
- in the Execute procedure of the TThread do nothing but call TThread.Queue
- have the TThread terminate itself and free the TThread object.

?

I agree that this is possible but for me it is a decently clumsy workaround.

OTOH, as supposedly nobody ever on purpose calls
Application.QueueAsyncCall from the main thread it does not do much harm (other than eating up some bytes of memory).

But provided this we can also just leave the implementation I did in it's current state and ignore the small incompatibility.

-Michael

Reply by email

Michael Van Canneyt
to Michael Schnell
Michael Schnell wrote 14 lines
On 08/20/2014 11:12 AM, Michael Van Canneyt wrote: > You can perfectly work around this by implementing > Application.QueueAsnycCall so that it creates a thread which does the call > to TThread.Queue. Do you mean that for an implementation of "Application.QueueAsyncCall" I should - Check if we are in the Main thread - if yes create a Dummy TThread - in the Execute procedure of the TThread do nothing but call TThread.Queue - have the TThread terminate itself and free the TThread object. ?

Yes.

Show quoted text 5 lines
I agree that this is possible but for me it is a decently clumsy workaround. OTOH, as supposedly nobody ever on purpose calls Application.QueueAsyncCall from the main thread it does not do much harm (other than eating up some bytes of memory).

Exactly.

Michael.

Reply by email

Michael Schnell
to Michael Van Canneyt
Michael Van Canneyt wrote 8 lines
> > OTOH, as supposedly nobody ever on purpose calls > Application.QueueAsyncCall from the main thread it does not do much > harm (other than eating up some bytes of memory). Exactly.

So I will proceed as you said.

Thanks,
-Michael

Reply by email