Currently, we pretend that each application has the device (configuration) to itself. Simply running applications is (more or less by accident) okay, but there are problems with debugging and remote mounts.
Problem 1: When starting debugging, we kill all other instances of gdbserver. While this ensures that the respective port is available, it also aborts all other debugging sessions on the device.
Problem 2: A device configuration's port list is "local" to every application that uses it, due to the value-semantics of the device confgurations. So if we start two debugging sessions, both potentially use the same port, and one of them will fail.
Solution 1: Don't kill running gdbserver processes at the start of a debugging session. Note that this creates a new problem, namely that a missed clean-up from an older debugging session (e.g. due to a Creator crash) will then block that port "forever". This might be mitigated by better error messages ("gdbserver start failed. It tried to use port x. Is it perhaps not available?") and the ability for the user to kill processes (e.g. a line edit for the process name and a "kill" button, or perhaps the output of "ps aux" in a table view with the ability to kill entries).
Note that we also have to make sure the name of the pipe from which we read output should be application specific, e.g. "app_output_<app name>".
Solution 2: The MaemoDeviceConfigurations should only ever be available as Shared Pointers. The port list is created once from the respective line edit and gets acquirePort() and releasePort() methods, The former is called e.g. on the start of a debugging session or on a remote mount, the latter is called at the end of a debugging session and after an unmount. Note: We should make the list of ports we currently believe to be in use available to the user and allow him/her to reset it ("I happen to know that this port is available"). Note also that it would be even better if there was a non-destructive way to test whether a port is currently in use, but there probably isn't.

We could also support the user by finding out which ports are currently in use on the device (e.g. by calling netstat). It would be ideal if we could tell the user which ports were used by which process (though the busybox netstat does not seem to support that feature directly).

UPDATE: Solution 2 is actually MUCH easier AND MORE RELIABLE - we don't need shared pointers etc. It works like this: Before we do anything pertaining to a run/debug control, we run netstat on the device and check which ones of the device configuration's ports are currently listed as listening or connected. We remove those from the list and keep the rest as the resource for this run control. Now every service chooses one (perhaps a random one to minimize the risk of a race condition) and removes it from that "run control global" list. THIS SOLVES ALL OF OUR PROBLEMS, because we don't need to remember information that can always get out of sync with reality, but we actually KNOW which ports we can use.