PostMessage -> Runerror(6)

[mschnell]

MarcoV,

Would you be happy with MSE's inter thread event scheduling mechanism that is free from any Windowisms ?

With Martin's approving and help, some time ago I got quite far porting this to Lazarus. It did work in Linux and I'm sure that I would get it work with Lazarus/Windows as well. But as there is a complete infrastructure of several MSE RTL units it uses, i found that it's not viable to implement it in Lazarus side-by side with the "Message" mechanism provided there.

IMHO it would be a great improvement for Lazarus and FPC if this mechanism would be part of the FPC RTL and Lazarus would implement it's Delphi/Windows compatible "Message"-mechanism on top of this, dropping the GUI binding of this stuff and preventing the LCL for Linux and Mac to implement it's own Message queue mechanism.

What do you think ?
-Michael

[marcov]

Would you be happy with MSE's inter thread event scheduling mechanism that is free from any Windowisms ?

For what?

With Martin's approving and help, some time ago I got quite far porting this to Lazarus. It did work in Linux and I'm sure that I would get it work with Lazarus/Windows as well. But as there is a complete infrastructure of several MSE RTL units it uses, i found that it's not viable to implement it in Lazarus side-by side with the "Message" mechanism provided there.

I think there are enough ways to do multi thread synchronization, with tthread.queue (which is also useful outside of Lazarus).

IMHO it would be a great improvement for Lazarus and FPC if this mechanism would be part of the FPC RTL and Lazarus would implement it's Delphi/Windows compatible "Message"-mechanism on top of this, dropping the GUI binding of this stuff and preventing the LCL for Linux and Mac to implement it's own Message queue mechanism.

Well, the main point is that I don't see the use of emulating a windows based message system. Martin's or the old one.

[mschnell]

For what?

having a worker thread asynchronously fire an event in the main thread. Such asynchronous events need to be queued as there might be multiple threads that fire them and additionally timers (also done independently of the GUI in MSE), and - if a GUI is attached - events initiated by the GUI.

-Michael

[mschnell]

Well, the main point is that I don't see the use of emulating a windows based message system. Martin's or the old one.

I really don't see your point here.
"a windows based message system" is a (of course very restricted and propriety) way to implement an inter-thread event firing system.

MSE defines a platform-independent versatile object-based inter-thread event firing system, and provides an implementation for Linux (and supposedly for Mac and Windows, too).

Of course based on this it's easy to provide the restricted Windows-compatible "Message" functions as well, e.g. for those porting Delphi projects.

-Michael

[mschnell]

tthread.queue

I don't find a queue property in TThread (as defined in Classes.inc).

-Michael

[marcov]

tthread.queue

I don't find a queue property in TThread (as defined in Classes.inc).

http://www.lazarusforum.de/viewtopic.php?p=40941#p40941" onclick="window.open(this.href);return false;

[mschnell]

http://www.lazarusforum.de/viewtopic.php?p=40941#p40941

OK, I see that in (Turbo-) Delphi TThread.Queue results in a call to TThread.Synchronize with the second parameter set to true. I tested that this really works like Synchronize but does not stall the thread. I never used this as TThrfead.queue is not described in the documentation .

In fact obviously you are making fun of me

You stated that you don't like that the Windowish Message sent to the main thread only provides four 32 Bit values. In fact three 32 Bit values can be used as parameters while the first one determines the event handler function to be used.

TThread.Queue can only denote the event handler function and provides no parameter at all. It obviously can very easily be implemented with ten lines of code on top of LCL's Message and "Procedure...Message" if only Message sending would not be broken for Linux in the latest version in the svn.

I feel that three 32 Bit values is better than no parameter at all, but a decent implementation should provide a serious Event Object as a parameter to a kind of "Procedure...Event" syntax or as a parameter to an general event handler of TApplication. So the Event Object could provide a procedural parameter for the procedure that is scheduled and (marshalized and) queued parameters for same (similar to an RPC).

-Michael

[mschnell]

Gibt es einen Bug-Report ?

Jetzt schon...

Welche ID ?
-Michael

[marcov]

TThread.Queue can only denote the event handler function and provides no parameter at all. It obviously can very easily be implemented with ten lines of code on top of LCL's Message and "Procedure...Message" if only Message sending would not be broken for Linux in the latest version in the svn.

It does. It can synchonize _different_ procedures into the mainthread, which are akin to different windows messages. For additional parameters, I'm not sure that it should be system provided.

I feel that three 32 Bit values is better than no parameter at all,
but a decent implementation should provide a serious Event Object as a parameter to a kind of "Procedure...Event" syntax or as a parameter to an general event handler of TApplication. So the Event Object could provide a procedural parameter for the procedure that is scheduled and (marshalized and) queued parameters for same (similar to an RPC).

That's a layer over the basic queueing system. I don't think predefining a near empty base object does much for that. And I would prefer a pool based system, to avoid the repeated construction and destruction

[mschnell]

It does. It can synchonize _different_ procedures into the mainthread, which are akin to different windows messages.

Makes a plus of 96 Bit for Windows Messages in a W32 system.

For additional parameters, I'm not sure that it should be system provided.

As the parameters can be modified before the event is executed, they need to be queued with the event call request. It would be a great plus if the user software does not need to do this.

(In our (embedded) (Delphi-) software we usually use a TThreadList or similar to hold the parameter values for events (fire by SendMessage) and the event handler code takes and removes them. Not comfortable, but it works.)

I don't think predefining a near empty base object does much for that.

agreed, So I vote for a queue of records. We need 2 Integers/Pointers for the Procedure and it's self Pointer, one Integer/Pointer for an optional parameter definition on the Heap, and when we add another Integer we can even for Delphi-Compatibility reproduce the Windowish SendMessage stuff without an additional heap allocation.

-Michael

[Kernel]

@mschell

Bug-ID : 0017548

[mschnell]

@mschell
Bug-ID : 0017548

Great, Thanks.

Leider kann ich es nicht ausprobieren, weil ich seit einiger Zeit mit der aktuellen svn-Version vom fpc die aktuelle svn-Version von Lazarus nicht mehr übersetzt bekomme.

-Michael

[af0815]

Aktueller Stand von svn von WE mit svn von Lazarus war kein Problem.

[Kernel]

Kann ich leider nicht bestätigen.
Der Fehler scheint bei mir nur sporadischer, resp. seltener aufzutreten.