在另一个线程中运行在 python3 中的非阻塞套接字服务器

Question

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.

Answer 1

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 distributed-computing many-to-many processes' communicating architectures )