PR# 19315 EiffelProcess ECF concurrency capability to "none"

The BASE_PROCESS classes do not support yet passing an agent to read the output of the process.
While BASE_PROCESS is not fully functional as a replacement for EiffelProcess, please set the ECF concurrency capability to "none", just for the same reason you had to do that for the EiffelThread library.

In order to avoid duplicating classes (one which works in single-threaded mode and one which works in multi-threaded mode) we have been relying on PLATFORM.is_thread_capable. This has been working fine so far (and as a matter of fact it was a precondition of the features in EiffelThread and EiffelProcess), so there is not reason it should not work anymore just because you introduced the notion of capability in ECF.
In the past we had to duplicate classes for classic and dotnet compilation modes. This was a maintenance nightmare, Now we are not using dotnet anymore, and we are happy not having to maintain duplicated classes anymore. So we don't want to come back to this maintenance nightmare with duplicated classes, one of single-threaded mode and the other one for multi-threaded mode.

--
Eric Bezault

You can pass an agent to WEL_PROCESS_LAUNCHER.launch to get the output. it works fine for us. And the agent is called as the output arrives, possibly several times based on the setting `block_size'.
And we wrote a descendant of WEL_PROCESS_LAUNCHER where you can pass some input text when launching the process.

I would have to inspect all our usage of PROCESS to figure out whether a fully functional BASE_PROCESS would work for us. And it might be that we would have to do the job of PROCESS (create a thread etc.) to use BASE_PROCESS. All that just because PROCESS does not want to rely on the {PLATFORM}.is_thread_capable anymore, but rely on ECF instead. 
A lot of work for us, for something which has been working fine for us so far. Needless to say that we would prefer to see the issues that are blocking us (e.g. console on Windows 2008, agent objects in storable) to be addressed first.

--
Eric Bezault

Could you confirm that this alternate route does not offer redirections? Also if BASE_PROCESS had redirections as I described them, would this be enough?

Could you confirm that this alternate route does not offer redirections? Also if BASE_PROCESS had redirections as I described them, would this be enough?

One alternative for us is to use WEL_PROCESS_LAUNCHER.

--
Eric Bezault

While we do not object to your suggestions, the reason we put it in place the restriction is that like you many users were bitten by the runtime violation which would force them to run in multithreaded mode just because of this library. So they had to either eat the bullet or drop their process usage. Now, instead of being bitten at runtime, they will know immediately instead of waiting execution to realize they have to run in multithreaded mode to use the process library.

To help us understand why the switch to the base process library is not ideal, we would need to know more about your alternate route. Could you tell us what replacement do you use when you are not using multithreading? Also if you are using redirections, what do you use instead when not in mulithreaded mode?

Below is not a reply but more background on this issue and what we are currently doing to address it:
<<
The main difference between the base and full process library is redirection because it is using threads to perform non-blo
....
Output truncated, Click download to get the full message

I shall repeat that we do not want to maintain multiple versions of the same code for MT and non-MT mode. It is far better that execution path branching is done in Eiffel code instead of in the .ecf' xml data. xml should be no substitute for Eiffel.

--
Ivan