Tracer cannot cope with console inheritance

[Jiri Svoboda]

Trunk r4642. With console inheritance in place the tracer tries to start up the binary which it is supposed to trace on the same VC as itself. The application does not seem to work (produces no output), possibly being blocked by the already connected tracer.

Tracer should either be made capable of sharing the console with the app or, more simply, start the app on a different VC.

[Jiri Svoboda]

There are two interesting issues here:

1. It is not possible for an application to be blocked in getchar() and printf() at the same time, because both functions will use a single phone. This should be solved in the future by using multiple connections.

2. It is very problematic to wait for two (or more) different events, such as two different IPC messages, an IPC message and an event from another fibril/thread etc. Ideally I would like to have some simple and universal way to wait for two or more things happening (similar to select() or WaitForMultipleObjects()). One solution would be to have some synchronization primitive used for waiting and expose it whenever there is some operation/event we want to wait for + some function to wait for a set of these primitives.

I worked around both issues. As for issue 1 I switched to reading key events (which goes directly to the console), thus printf() and console_get_event() use different phones and the problem goes away. As for issue 2 I created a dedicated fibril for reading console events that signals the global state CV. It is interesting to note that this fibril can never finish (it can only wait on one thing — console events) and so it relies on being cleaned up when the whole task terminates.

In any case the tracer now works as of r4656, even when the app runs at the same VC as the tracer. Also, the tracer will now exit as soon as the app does.