Suggestion for Processes

[venthur]

Maybe we should think about dropping network support (do we really need it?) and go for processes instead of threads.

The idea is stolen from the framework the google ai-challenge uses. It looks roughtly like this:

The server starts the Agents as own process using Popen. With Popen each process can have it's own stdin/out/err. Agents receive their updates via stdin (raw_input) and send their commands using stdout (print). Agents cannot see the output of the other Agents since they have their stdin/out/err piped to the master process.

Network support can be added later by wrapping the communication, but we should think about the necessity and usefulness of this feature. Think of timeouts.

I can provide example code if needed.

Pro:

• Agents run in their own process and cannot interfere (i.e. cheat) with each other
• No problems w/ logging
• Easy to start tournament with a script
• No fiddeling with PYTHONPATH
• We could provide infrastructure for automatic matches on a website, for testing during the preparation of the tournament.

Con:

• Dunno

[otizonaizit]

I like the idea, but I would use a FIFO file instead of relying on stdout/stderr. Otherwise image the total mess when you try to use print in your player...

Maybe we should think about dropping network support (do we really need it?) and go for processes instead of threads.

The idea is stolen from the framework the google ai-challenge uses. It looks roughtly like this:

The server starts the Agents as own process using Popen. With Popen each process can have it's own stdin/out/err. Agents receive their updates via stdin (raw_input) and send their commands using stdout (print). Agents cannot see the output of the other Agents since they have their stdin/out/err piped to the master process.

Network support can be added later by wrapping the communication, but we should think about the necessity and usefulness of this feature. Think of timeouts.

I can provide example code if needed.

Pro:

• Agents run in their own process and cannot interfere (i.e. cheat) with each other
• No problems w/ logging
• Easy to start tournament with a script
• No fiddeling with PYTHONPATH
• We could provide infrastructure for automatic matches on a website, for testing during the preparation of the tournament.

Con:

• Dunno

Reply to this email directly or view it on GitHub: https://github.com/Debilski/pelita/issues/64

[Debilski]

Cannot say anything about the relative speed (I suppose no-one can without testing) but that thread-less approach would also work with socket connections (or zeromq or whatnot). Both would client-wise look like

while True:
    inp = connection.read() # or connection.recv()
    value = process(inp)
    connection.write() # or connection.send()

The main advantage of stdin/stdout would mainly be that the client needs no code to wait for a connection to be established since stdin/stdout would already be there. All other pro arguments are more or less solvable with the current or similar code via general sockets. Alternatively, a client could be given a filesocket as an argument and try to directly use that of course, but this opens issues for different operating systems.

@otizonaizit: Printing could be solved when we switch to Python 3. We’d then just redefine it. :)

[Debilski]

I guess we’ll close this one now that zmq is being used.

For the record: I tried using process-based FIFO communication but it was getting pretty unwieldy and showed the same locking issues as the BSD sockets.

[Debilski]

Closing. zmq (or whatever comes next) works good enough for the moment.