Verdict in non-stub communication tasks

[eriks245]

Before this commit (1d69d0d) there was an attempt to kill the user solution whenever the manager decides to finish.

I think the original idea was to provide a proper verdict for the first thing that failed in the user submission.
For example, the user made an invalid query => the manager gives WA but doesn't respond anymore => the user submission can crash by not handling the (missing) response from the manager properly.

The old idea of sending a SIGINT to the user whenever the manager wants to finish is flawed

• If the submission is killed, then the response of the manager is ignored and this is shown as RTE to the user
• If the user submission is correct, then there is some delay between sending the last message to the manager and the process actually terminating. This is especially problematic if the user has allocated a lot of memory. In this case it might happen that the communication manager <-> cms is faster then the deallocation of this memory. In particular, a correct submission would receive RTE in such a case.

Since the manager response is ignored, when the solution crashes, it is probably better to mimic the same behavior as for stub problems. So the additional pipes / communication manager <-> cms seems unnecessary

[fagu]

Good observation. Thanks for fixing this!

This was indeed the original idea. You can carefully implement a stub to terminate the solution when it learns from the manager that the query was invalid. For stub-less tasks, you'd have to tell the participants how to do this or they may get a meaningless verdict after making an invalid query.

I suppose the code you removed has not worked at least since we returned to the upstream version of isolate. I think that maybe historically, our custom version of isolate would, when it receives SIGINT, terminate the solution and report it as a success. (There were problems with that too, though.) See ioi-germany/isolate@244be6e.

Somewhat related:

1. A recent interesting discussion of communication tasks in upstream CMS: Fix controller hang when submission exits early cms-dev/cms#1695
2. Some earlier discussions about the motivation: Grader-less communication task type cms-dev/cms#993