Beginner-Question: Server Prog, BackgroundWorker, unknown thread

[t2000 1]

Hello,

I have a new project and want to use OTL (BackgroundWorker). I have read the book, watched the 3 videos and now I try to programming.
The situation:
The main program is a console application (later a windows service)
I use the REST XData from TMS software. This is important, because I want to schedule a WorkerItem from a REST Call in a (for me unknown) thread.
(we can accept here, that the function for the REST call is equal to the .execute-function of a thread)
The REST call must close before the work (WorkerItem) is ending.
The Backgroundworker is declared in the MainThread. Ich have a processloop.
Ok.

In the REST call I want to start a working task. After start, the REST gives a ok result and is closing. But the working task is still working.
I think, I have to send a message from the REST call to the MainThread/BackgroundWorker with the information about the procedure-call and the data-parameter.
But how can I do this?

Thank you
Thomas

 

 

[Primož Gabrijelčič 223]

You can probably use PostThreadMessage Windows API to post a message directly to the main thread. Then you process this message in your process loop.

[Lars Fosdal 1793]

@Primož Gabrijelčič From the wishful thinking department:
I'd love to see OTL evolve to support Linux/MacOS, iOS and Android.
Hence, I'd love to see solutions that do NOT use Windows messaging - or at least hide it inside the notification implementation.

[t2000 1]

Oh, so simple. I will try it.

Thank you

[t2000 1]

7 minutes ago, Lars Fosdal said:

@Primož Gabrijelčič From the wishful thinking department:
I'd love to see OTL evolve to support Linux/MacOS, iOS and Android.
Hence, I'd love to see solutions that do NOT use Windows messaging - or at least hide it inside the notification implementation.

I too. Our next step is to build our server for linux.

[Primož Gabrijelčič 223]

24 minutes ago, Lars Fosdal said:

@Primož Gabrijelčič From the wishful thinking department:
I'd love to see OTL evolve to support Linux/MacOS, iOS and Android.
Hence, I'd love to see solutions that do NOT use Windows messaging - or at least hide it inside the notification implementation.

I would love that too!

[t2000 1]

It works. I don't know why I didn't try it right away.

 

I have taken the TOmniBlockingCollection (created in my ServerApp.MainObject) to write the data from the foreign thread and read it in MainThread.
Is this ok or would you take the TOmniMessageQueue? (My data is a record with a reference to a procedure and a string variable)

[Primož Gabrijelčič 223]

Sure, TOmniBlockingCollection is fine.

[Vincent Parrett 762]

12 hours ago, Lars Fosdal said:

@Primož Gabrijelčič From the wishful thinking department:
I'd love to see OTL evolve to support Linux/MacOS, iOS and Android.
Hence, I'd love to see solutions that do NOT use Windows messaging - or at least hide it inside the notification implementation.

It's currently tied to the vcl (only in DSiWin32.pas) so if anyone is trying to use Omni in a console/service running in a windows docker container they will be blocked. For now I just commented out the offending code (reading/writing fonts to registry, which isn't needed for omni). 
 

[Primož Gabrijelčič 223]

Quote

It's currently tied to the vcl (only in DSiWin32.pas)

I have fixed that (just now). DSiWin32 no longer uses Vcl.Graphics if symbol NoVCL is defined.

[Vincent Parrett 762]

This is a good workaround if people are just using from the repo, but if they use Delphinus or DPM (I was planning on creating packages as I have a package that has a dependency on Omni) then that's a bit problematic. Perhaps defining NoVcl default would be better?  

[Primož Gabrijelčič 223]

Defining NoVCL where? I don't understand.

[Vincent Parrett 762]

at the top of DSiWin32.pas

 

People can comment it out to enable those functions.

 

Alternatively, switch it around, e.g.

 

{$IFDEF UseVcl}

readfont etc

{$ENDIF}

 

Then they need to define UseVcl. 

 

There's likely very few people using those functions so the impact would be low. 

 

[Primož Gabrijelčič 223]

Ah, I get it.

 

I don't like to break compatibility but this is something that could be useful, indeed. Alternatively, I may move this functionality into DSiWin32.VCL (which may be altogether a better idea).

[Primož Gabrijelčič 223]

3 hours ago, Primož Gabrijelčič said:

 Alternatively, I may move this functionality into DSiWin32.VCL ...

Done. OmniThreadLibrary now uses only the DSiWin32 part and ignores DSiWin32.VCL.

[Vincent Parrett 762]

Excellent, thanks!