Jump to content
t2000

Beginner-Question: Server Prog, BackgroundWorker, unknown thread

Recommended Posts

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

 

 

 

Share this post


Link to post

@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.

  • Like 2

Share this post


Link to post
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.

Share this post


Link to post
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!

  • Like 3

Share this post


Link to post

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)

Share this post


Link to post
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). 
 

  • Thanks 1

Share this post


Link to post
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.

Share this post


Link to post

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?  

Share this post


Link to post

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. 

 

Share this post


Link to post

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).

Share this post


Link to post
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.

  • Thanks 1

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×