Introduction

Flask is not usually "blocking a thread" by accident. What is really happening is that a request handler is doing expensive OpenFace work synchronously, so the worker handling that request stays busy until inference finishes.

Why It Feels Like Flask Is Blocking

A normal Flask route runs synchronously. If that route loads an image, runs alignment, computes embeddings, and waits for disk or CPU-heavy model work, the request thread or process cannot serve anything else until it returns.

That becomes especially obvious when using Flask's built-in development server. The dev server is fine for debugging, but it is not designed to hide slow inference workloads.

In other words, Flask is not the root cause. The root cause is long-running work inside the request path.

Keep Model Loading Out of the Request Handler

One easy performance mistake is creating heavy OpenFace objects on every request. Load static resources once at process startup instead.

1from flask import Flask, request, jsonify
2import subprocess
3import tempfile
4from pathlib import Path
5
6app = Flask(__name__)
7
8OPENFACE_BIN = "FaceLandmarkImg"
9OUTPUT_DIR = Path("/tmp/openface")
10OUTPUT_DIR.mkdir(parents=True, exist_ok=True)
11
12def run_openface(image_path: str) -> str:
13    completed = subprocess.run(
14        [OPENFACE_BIN, "-f", image_path, "-out_dir", str(OUTPUT_DIR)],
15        check=True,
16        capture_output=True,
17        text=True,
18    )
19    return completed.stdout

Even if you do nothing else, moving initialization out of the route can shave off a surprising amount of latency.

Offload Expensive Work to a Background Worker

If face processing takes noticeable time, do not make the HTTP request wait in the main worker. Offload the job to another process and return a job identifier immediately.

1from concurrent.futures import ProcessPoolExecutor
2from uuid import uuid4
3
4executor = ProcessPoolExecutor(max_workers=2)
5jobs = {}
6
7@app.post("/analyze")
8def analyze():
9    uploaded = request.files["image"]
10
11    with tempfile.NamedTemporaryFile(delete=False, suffix=".jpg") as temp:
12        uploaded.save(temp.name)
13        job_id = str(uuid4())
14        jobs[job_id] = executor.submit(run_openface, temp.name)
15
16    return jsonify({"job_id": job_id}), 202
17
18@app.get("/result/<job_id>")
19def result(job_id):
20    future = jobs.get(job_id)
21    if future is None:
22        return jsonify({"error": "unknown job"}), 404
23    if not future.done():
24        return jsonify({"status": "processing"}), 202
25    return jsonify({"status": "done", "output": future.result()})

This changes the user experience from "browser waits while the server is busy" to "submit a job, then poll or notify when it completes."

Why Processes Often Beat Threads Here

OpenFace-style inference and image processing are usually CPU-heavy, and Python threads do not magically turn CPU-bound work into parallel work. If the heavy portion stays inside Python, a process pool or an external task queue is often a better fit than a thread pool.

Threads are still useful for I/O-bound work, but if the request is burning CPU for image analysis, extra threads often just mean extra waiting.

Use a Real WSGI or ASGI Deployment

Running under Gunicorn or another production server is also important. Multiple worker processes let one slow request avoid monopolizing the whole app.

gunicorn -w 4 "app:app"

That does not eliminate slow inference, but it gives the application more capacity than the single-process development server.

Separate the API From the Inference Service

For heavier workloads, the cleanest architecture is often:

1. Flask API receives upload,
2. a worker process or queue handles OpenFace,
3. results are stored somewhere durable,
4. the client polls or receives a callback.

That separation prevents web responsiveness from depending directly on model latency.

Tools such as Celery, RQ, or a message queue can formalize this pattern, but the architectural point matters more than the library choice.

Be Careful With Shared State

If you keep model state or caches in memory, make sure you understand whether they are safe to share across threads or processes. Some native libraries behave badly when accessed concurrently without clear isolation.

A simple rule is: if you are unsure, isolate the heavy inference in worker processes instead of sharing mutable model state inside request threads.

Common Pitfalls

The biggest pitfall is blaming Flask when the real issue is synchronous inference inside a request handler. Any synchronous web framework would show the same symptom.

Another mistake is using the development server as a performance baseline. It is meant for development convenience, not production concurrency.

Developers also often reload models or helper objects on every request, which adds avoidable latency before inference even begins.

Finally, do not assume a thread pool is enough for CPU-heavy image analysis. For many OpenFace workloads, a process-based design is the safer default.

Summary

• Flask handlers are synchronous, so heavy OpenFace work ties up the worker serving that request.
• Load expensive model resources once instead of rebuilding them on every call.
• Offload long-running inference to a background process or task queue.
• Use a production server such as Gunicorn instead of relying on Flask's dev server.
• If the workload is CPU-heavy, processes are usually a better fit than threads.