Issue when emitting in threads

[ItachiSan]

Hi,

I am currently facing issues when emitting an event in a separate thread.

In short:

• Main app runs as usual
• When task is open, I start a thread in the background
• In the background thread, I use flask_socketio.emit to emit events
• In an Angular app I react to those events

In short,

• events from all around the app are detected
• events from the worker thread do not work

I have this issue when running the app via socketio.run or eventlet.wsgi.server.
When using flask run or gunicorn I have no issues.

Any clue on the why?

I can provide a minimal example if needed.

[miguelgrinberg]

Please do not write issues on this package when you have a question about your own application. The discussion board is the appropriate place to ask question, the issues board is used to track bugs in the package.

Is your background thread a real thread or a greenlet? You can't emit from a real thread if you are using eventlet, that is a limitation of the concurrency model used by eventlet and not of this package. But if you run your background job as a greenlet then it should work fine.

[miguelgrinberg]

When using the eventlet worker, Gunicorn monkey patches the Python standard library to replace threads with greenlets.

[ItachiSan]

Okay, I fixed all the nasty issues. 😄

In short, I replaced the

app = create_app()
socketio.run(app, ...)

with

eventlet.patcher.monkey_patch()
app = create_app()
eventlet.wsgi.server(eventlet.listen(...), app)

But the second approach made a piece of code reliant on requests to stop working with a weird SSLContext recursion issue.

I fixed that with:

if "eventlet" in sys.modules:
    from eventlet.patcher import import_patched
    # Import urllib3 as it is the one used behind the scenes for connection management
    urllib3 = import_patched("urllib3")
    # Import requests with all eventlet patching magic
    requests = import_patched("requests")
else:
    import requests

and now all is eventlet friendly 😉

I suppose it can be mentioned somewhere that monkey patching should be used in order for Flask-Socket.IO to work?

[miguelgrinberg]

Flask-SocketIO works without monkey patching. Only your application needs it.

[ItachiSan]

I partially disagree: Flask-SocketIO .run() started with eventlet although the environment was not monkey-patched and I had no clear sign from Flask-SocketIO that that was the case.

I did a bit of debugging and it seems some external Flask-SocketIO dependencies try to import eventlet, ultimately making the Engine.IO server running via eventlet and thus making the monkey patching required.

Essentially, if eventlet is available as a package (e.g. import eventlet), .run() will use it and monkey-patching is required.

I can re-create the situation and share it if it can help.

[miguelgrinberg]

This works as designed. From the documentation:

In production mode the eventlet web server is used if available, else the gevent web server is used. If eventlet and gevent are not installed, the Werkzeug development web server is used.

Also the definition of async_mode in the API reference section:

async_mode – The asynchronous model to use. See the Deployment section in the documentation for a description of the available options. Valid async modes are threading, eventlet, gevent and gevent_uwsgi. If this argument is not given, eventlet is tried first, then gevent_uwsgi, then gevent, and finally threading. The first async mode that has all its dependencies installed is then one that is chosen.

As I said above, nothing in this package requires monkey patching. It is the dependencies that you use in your application that require it. Flask-SocketIO has no way to know what your application does or how it does it, it is up to you as a developer to recognize the need to monkey patch (or use an alternative solution that is async-native, which is preferable) if you decide to use eventlet.