Prowin32 and multicore CPUs

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

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

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

Why?

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

Regards,

George

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.

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)

@broncp

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

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

What's with the new keywords? Nothing wrong with

RUN foo ASYNCHRONOUS

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

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.

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

As to why, see www.oehive.org/MultiThread

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.