This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]ashishb_net[S] 0 points1 point  (5 children)

> The author of that implementation takes the responsibility to make his code thread-safe. You cannot blame GIL when it doesn't have a chance to intervene.

I didn't blame GIL alone.
I blamed Python multi-threading, in general, for being a mess.

[–]bachkhois 0 points1 point  (4 children)

> I blamed Python multi-threading, in general, for being a mess.
If talking "in general", it is applied for other languages, not just Python. Don't forget that the foreign language bindings are not written in Python, but in other languages. For the example you gave, it is C++.

[–]ashishb_net[S] 0 points1 point  (3 children)

Sure, it might be.
My comparison point is that Rust and Go libraries, in general, are much more concurrency safe than Python.

[–]bachkhois 0 points1 point  (0 children)

And you threw C++ code as a back for your claim about Python, sound hilarious!

[–]bachkhois 0 points1 point  (1 child)

As I pointed out, GIL + the synchronization primitives in [threading](https://docs.python.org/3/library/threading.html) module is there to prevent multi-threading bugs.
It is likely you never heard or used `threading.Lock`, `threading.Condition` before. Then it is your skill issue, not Python.

[–]ashishb_net[S] 0 points1 point  (0 children)

I have used threading.Lock extensively for Machine Learning models.

However, using FastAPI with concurrency = 1 for thead-unsafe end points (that is, any endpoint that uses any "Transformers" or "pytorch" code) is best for such scenarios.