Yesterday, I had a discussion with a colleague about programming languages.

He said that he did not like Object-Pascal / fpc because it lacks the concept of "signals" he finds in other languages / libraries. (He is not an expert but discusses on base of rumors he collected.)

With "signals" he meant a kind of multi-target events.

He described that multiple parts (units) of a program (or even units within a set of sunning programs) can "subscribe" to a signal (or several of them), and whenever anyone "rises" a signal all subscribers get notified and can react.

Seemingly the execution line in such a "unit" might be as well the main thread or a worker-thread (or even another task/program) and the event handler can be defined to work on this thread (he did not elaborate if always or optionally a newly created thread can be used).

Unfortunately I was not able to come up with a similarly powerful concept available in fpc.

Any suggestions ?

-Michael

You can use the Observer pattern; it is in the classes unit.

And to be honest, this is not a language concept, but a library concept. It can be easily implemented.

Michael.

Michael Van Canneyt wrote

You can use the Observer pattern; it is in the classes unit.

I'll take a look.

And to be honest, this is not a language concept, but a library concept.

AFAIK he mentioned QT as a library providing this.

It can be easily implemented.

If so I assume that somebody already did it.

To allow for doing this with thread, an event queue for worker threads needs to be provided.
In fact I already did some research on this issue. It does not seem a great problem, but to be decently done, IMHO the event queue code in the RTL should be re-used. But this does not seem to be a concept that is supported by the implementers of the RTL, as no public interface to same is provided.

-Michael

Again have a look at MSEgui, tobjectlinker in mseclasses.pas. It is not so easy to implement as it seems. ;-)

Martin

Yes, I have.

To allow for doing this with thread, an event queue for worker threads needs to be provided.

Huh? WHY ?

The implementation must be thread safe, but that's about it.

Michael.

It is. Depends on your definition of difficult, of course.

Michael.

Or the implemented functionality.

Martin

That's why:
https://www.youtube.com/watch?v=BKorP55Aqvg

Mattias

Nice :-)

-Michael

Absolutely. A signaling mechanism, synchronous, is not hard.

If you want asynchronous, or if you want the signal executed in the context of a thread in case of multiple threads, that is another matter.

Although I am having difficulty seeing how you would decide which signal must be executed in what thread... an object does not automatically belong to a thread...

Michael.

Michael Van Canneyt wrote

> To allow for doing this with thread, an event queue for worker > threads needs to be provided. Huh? WHY ?

When handling asynchronous Events with a thread, you need an event queue and a mechanism to have the thread sleep until the queue gets not-empty.

-Michael

Michael Van Canneyt wrote

Absolutely. A signaling mechanism, synchronous, is not hard.

I suppose an _synchronous_ mechanism can be done on base of or similar to "Dispatch".

But the signaling mechanism we talked about is obviously asynchronous.

-Michael

Sigh....

When you give specs like 'a signal mechanism', then "asynchronous operation" is *not* automatically implied.

In fact, it is a major shift in functionality.

Please look at the link Mattias provided.

It's enlightening.

Please tell the list afterwards which character you are...

Michael.

This may come as a shock to you, but no, it is not "obvious".

Michael.

Michael Van Canneyt wrote

> But the signaling mechanism we talked about is obviously asynchronous. This may come as a shock to you, but no, it is not "obvious".

???

I described: sending "Signals" from one thread to one or more others, sender and receipient can be as well the main thread as a worker thread.

To me this is "obviously" asynchronous.

-Michael

Michael Van Canneyt wrote

Please look at the link Mattias provided. It's enlightening.

In another forum I already used this video as an example myself.

Please read my initial post at the top of the thread: the request for sending "Signals" from one thread to one or more others, sender and recipient can be as well the main thread as a worker thread seems rather clear..

-Michael

Well, if you need that: the cross application requirement makes it rather tricky - threads are easy in comparison - you can use dbus. FPC has bindings for it. No need to reinvent the wheel.

I have a class based wrapper around it. I think you can find it somewhere in the list of articles I published.

Michael.

Yes, get him to state /exactly/ what language he's talking about that provides this facility, so that we're not groping in the dark based on your account of his recollection of the rumours he's picked up from sources that might not be reliable.

context of a thread in case of multiple threads, that is another matter.

Although I am having difficulty seeing how you would decide which signal

must be executed in what thread... an object does not automatically belong to a thread...

In Qt it does. Each QObject has a thread it is owned by and thus the signal handling mechanism knows to which thread to queue to deliver a signal to a certain object.

Regards,
Sven

That is an implementation detail of Qt. Not so in FPC.

In each case, if the requirement is that it must work cross-process, then all processes need to use the same protocol. So DBus is your best bet, since it is widely supported. I believe Qt uses it as well (or can use it).

Michael.

Making the appropriate ("signalable") Objects instances of TThread siblings would do the same trick.

But (as discussed before) with that such TThread-sibling instances would have to automatically have their own Event queue instance, and would need to be programmed in an event-driven way (like the main thread in Lazarus). (In fact this is what I feel in many cases would be the more appropriate way to do do worker threads anyway: I already suggested a "TThreadApplication" Type in Lazarus already ages ago)

-Michael

2014-09-26 6:37 GMT-03:00 Sven Barth :

This may help:
http://qt-project.org/doc/qt-4.8/threads-qobject.html#signals-and-slots-across-threads

Luiz

Michael Van Canneyt wrote

That is an implementation detail of Qt. Not so in FPC.

Correct.

Hence - if you say the signaling stuff is not / should not be a language feature but just a matter of a library (I don't disagree here) fpc is unrelated to this. I feel that fpc would have no problems with an implementation of an environment that allows for more than one thread that features event-driven programming (While Lazarus only allows for a single such "Main"-Thread. mse: I don't know, but I suspect that Martin did think about it.)

So DBus is your best bet, since it is widely supported. I believe Qt uses it as well (or can use it).

In fact my colleague did mention QT, I did point him to dbus after you mentioned it. dbus seems less bloated (if you don't need the QT GUI stuff).

-Michael

Mark Morgan Lloyd wrote

so that we're not groping in the dark based on your account of his recollection of the rumours he's picked up from sources that might not be reliable.

I was just trying to help fpc to be a winner (here and elsewhere). ;-)

In fact it seems that he was wrong assuming this to be a language feature. The experts here state that it's just library stuff that - of course - can be used / implemented via fpc.

Of course the colleague was not able to clearly distinguish between fpc and Lazarus. But we obviously are in the wrong forum here, as the "culprit" seems to be the inability of Lazarus LCL to do event driven programming in threads. Obviously a library with this feature can be created (the "closed" design of TThread - that includes a single main-thread event queue - in the RTL might force creating an alternative Thread container object though.)

-Michael

Which reminds me - how is that library (non-GUI event loop IIRC) coming along? Is there any code repository where interested people can look?

As I already pointed out multiple times it works just fine for me, but can't be included in the LCL as it needs TThread.Queue and same is not in the released version of fpc and hence not usable for "normal" users.

-Michael

So why not include your own version of TThread with IFDEFS to check for FPC version so it can be retired when an FPC 2.7.1+ is used/stable?

I don't see the problem.

I don't suppose it makes sense to do a version of TThread that does not reside in the rtl / and "classes" even if this somehow might be possible.

Moreover I did not find that anybody besides myself has been interested in this issue.

I seem to remember that I once posted a zip file with a current testing version (either here or in the Lazarus forum) but got no answer.

-Michael

Well, that says a lot, I suppose.

Reinier Olislagers wrote

Well, that says a lot, I suppose.

As it did work for me, it says that nobody is interested in an ActiveNoGUI Widget Type for Lazarus right now.

I can use it with the svn version of fpc if I want to.

So I decided to hold off until the released version of fpc does have the "ThreadExtensions" and try to integrate this Widget Type in the LCL.

-Michael

Thinking harder I remember that I did not send it to the Forum but in a private mail to the one person who seemed interested.

-Michael

ROTFLMAO!!! i can't count the number of times that i've been in the position of that "expert" in that video... lines are lines and kittens are kittens [smh] :lol:

We already implement equivalent of signals as I mentioned in Mitov.Runtime, however they are anonymous methods based, and we call them TMultiProc but they are the same thing. I even showed a code snippet in another post.

With best regards,
Boian Mitov

------------------------------------------------------- Mitov Software
www.mitov.com
-------------------------------------------------------

Interesting stuff !!

Is there any docs available ?

-Michael

In fact (to avoid an inconsistency with implementing TApplication.QueueAsyncCall) I suggested that I could do a (rather simple) patch for the future release of the RTL that provides a more appropriate Queue-feeding function than TThread.Queue. This attempt had been discouraged.

Seemingly opening the TThread event queue for use by the LCL is considered opening a can of worms.

-Michael

Working on the docs at the moment.
Trying to make a new release before my travel to ITDevCon. I will do 3 sessions covering different aspects of Mitov.Runtime there.

With best regards,
Boian Mitov

------------------------------------------------------- Mitov Software
www.mitov.com
-------------------------------------------------------