Prowin32 and multicore CPUs

Posted by cooper on 19-Mar-2015 11:11

Are there any plans to allow the prowin32.exe/ OpenEdge runtime utilize more than one CPU core (allow threading)?

It is really frustrating when I write a compicated program that takes some time to process and the runtime only uses ~25% of my cpu.

Dual or even Quadcore is the default since years and the OpenEdge Runtime should allow me to utilize the available power of these CPUs.

All Replies

Posted by Mike Fechner on 19-Mar-2015 11:14

Not what you’ll probably want to hear.
But (async) AppServer calls allow you to utilitze more CPU power already today.


Posted by cooper on 19-Mar-2015 11:44

Sadly I don't use the Appserver and probably never will.

Multithreading (on the client) should really be a high priority by now.

Posted by George Potemkin on 20-Mar-2015 02:03

> Sadly I don't use the Appserver and probably never will.


> Multithreading (on the client) should really be a high priority by now.

We have a few large customers and their priorities are different. They even don't use Windows (prowin32.exe). ;-)



Posted by Marian Edu on 20-Mar-2015 02:24

most probably there is some I/O activity there so not even a cpu is used most of the time (for abl, not .net) but anyway, do you expect the linear program to just magically execute on parallel with no changes to the code?

doubt adding threads, locking and synchronization is best addition to a 4gl... some things like guns need to be hidden away and that is for a good reason ;)

what would be nice though is a separate UI thread, same as you can find in Eclipse, so we can gave the choice to run something on background thread (with no UI access for longer running operations, will not block the UI) or in foreground but that will make the UI unresponsive so should be as short as possible.

Posted by bronco on 20-Mar-2015 02:54

Asking for MT, but AppServer is not an option. Interesting.

Somehow MT feels like opening Pandora's box. Marian's suggestion is interesting however, I foresee an EXECUTE BACKGROUND statement.

(edited: typo's)

Posted by cverbiest on 20-Mar-2015 03:45


> I foresee an EXECUTE BACKGROUND statement.

I wish I could share your optimism, this has been asked in Info Exchange sessions before, got massive votes but nothing seems to move.

I agree that full MT would probably be like opening Pandora's box, but a technique to keep the UI thread free to respond  to the user and the windows OS is AFAIK vital for a well behaving windows application.

Windows applications that do not respond in a timely fashion cause focus problems and "application not responding" messages.

Mike Fechner worked around the lack of a background thread by using a separate process and ZeroMQ in one of his demo applications. I like the demo but I think it's very un-ABL like to have to resort to such techniques unless they are incorporated into the language.

Posted by bronco on 20-Mar-2015 04:20

Well, I wasn't expressing optimism, I meant foresee in the context of "imagine". I imagined the realization of Marian's idea by the implementation of he EXECUTE BACKGROUND statement.

What is more likely though is that all this is never going to happen and the UI is left to the browser (which might not be a bad idea). Or maybe I'm just pessimistic :-)

Posted by Stefan Drissen on 20-Mar-2015 04:28

What's with the new keywords? Nothing wrong with


just need a second thread instead of an appserver to pick up the work.

Posted by Patrick Tingen on 20-Mar-2015 05:23

That would be cool, but I agree it would be like Pandora's box to Progress tech team. Suppose I spawn a second or third thread, how would locking then occur. Would it then be possible to lock yourself?

The easiest way to poor man's MT is probably not suitable for every problem, but in the past I have used it to calculate invoices for clients. This process was very time consuming. They ran it during the weekend, but as business grew, the weekend became too short :)

I speeded up the process by first eliminating parts that were not really necessary like the physical printing of the invoices. No need to wait for that. Next step was to split it up. Yes, here's your poor man's MT. We spawned N processes (configurable) and each process only processed customers where the customer number modulo N = <process number>. We were able to put back processing time to less than 6 hours.

Posted by bronco on 20-Mar-2015 06:59

If you want to eat an elephant, you chop it in pieces :-)

Posted by Thomas Mercer-Hursh on 20-Mar-2015 09:29

As to why, see

Yes, it is difficult.  Yes, it presents some possible hazards.  But, by the same token, there are some things which are close to impossible to do without it.  ABL is not just about easy problems.

This thread is closed