Search code examples
pythonmultithreadingsocketsasynchronousconcurrent-processing

Non-blocking socket server running in python3 in another thread

I would like to know the best way to run a non-blocking python3 socket server.

I currently have code that is:

def start(data):
    global sock
    try:

        sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
        sock.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)
        sock.bind(("0.0.0.0", 8080))

        sock.listen(2)

        while True:
            #Does something
            client.close()

    except KeyboardInterrupt:
        kill()

def kill():
    sock.close()

In my main program, how would I make this socket server run in the background (like, in another thread) and not block the main thread so I can continue to do other things in the main thread after the endpoint is created? For example, in my main thread I would like to be able to call createEndpoint(data) and then also call some other functions and etc.

Solution

  • Q : how would I make this … run in the background … and not block the main thread so I can continue…?

    This will never happen in Python3 as-is (since ever & as Guido ROSSUM declared himself, most probably will remain so, unless total re-engineering of the Python-interpreter will get first decided feasible and next successfully undertaken)

    Python and all it's threads are centrally controlled by a monopolistic singleton, the central unique shared resource of the Python{2|3} GIL-lock.

    The GIL-lock stepping principally re-serialises any just-[CONCURRENT] py-threads-based execution, so the result is a pure-[SERIAL] interleaved sequence ( right - principally avoiding any concurrency at all, the more any wished-to-have form of [PARALLEL]-code execution ).

    This said, one may jump out of this Python-by-design kept restriction and spawn a non-pythonic framework - like ZeroMQ, that works independently of that, sort of "besides" the python-interpreter, and that would handle all the signalling/messaging services independently over smart sockets (archetyped by agents' behaviours), having fully escaped from the known GIL-lock re-serialisation bottleneck for the performance ( and would also allow to harness the mix of colocated and many-to-many processes' communicating architectures )