-2

Using module-scope variables or global variable aren't thread-safe.

But what's about other like Blueprint?

I see in their document and many other code on git declares an instance of Blueprint as a module variable

http://flask.pocoo.org/docs/1.0/blueprints/

Exposing blueprint instance which can be changed in any request isnt wise choice. Why they dont declare it in some singleton or immutable object to prevent race condition?

I've read this answer. Working with a global singleton in Flask (WSGI), do I have to worry about race conditions?

Do i have to lock Blueprint instance in this case?

TomSawyer
  • 3,711
  • 6
  • 44
  • 79
  • What makes you think that blueprints change in every request? AFAIK they never change. – zvone Apr 14 '19 at 12:32
  • 1
    *Using module-scope variables or global variable aren't thread-safe.*: Module-scope variables **are** global variables. They are not thread safe or unsafe just because they are globals. – Martijn Pieters Apr 14 '19 at 12:40
  • @zvone its exposed so we can change it anytime on any request accidentally – TomSawyer Apr 14 '19 at 13:06
  • @MartijnPieters so why they declared Blueprint instance as module-scope variable when itsn't safe? Have no idea what do you try to prove. – TomSawyer Apr 14 '19 at 13:08
  • @TomSawyer: who says it isn't safe? It's not being altered from a view, is it? – Martijn Pieters Apr 14 '19 at 13:15
  • @MartijnPieters then you didn't answer the question, i see many declare Blueprint like this and not single of them bat an eye. – TomSawyer Apr 14 '19 at 13:18
  • @TomSawyer: no, no-one bats an eye because it isn't a problem. – Martijn Pieters Apr 14 '19 at 13:19
  • 1
    @TomSawyer: at this point I'm not certain what you are trying to ask here any more. In the normal course of a Flask application, there is no need to mutate blueprints. It would only be a problem if you actually mutated blueprints in a view. Then you'd maybe have to consider locking, but not before. – Martijn Pieters Apr 14 '19 at 13:21

1 Answers1

2

Blueprints are not normally mutated (modified) when handling routes, so no, no locking is required.

Only when handling requests, so when views are called, could there be multiple threads (one per incoming request). This depends on the specifics of the WSGI server being used to serve your Flask app. By that time, all Blueprint configuration has already completed.

In the same vein, in the question you link to, the view code is not mutating the Flask object, either. There they are mutating multiple shared values (a, b and c), and to ensure that those 3 values are changed atomically (all changed together as if one value), a lock is needed. That's not specific to Flask, or to globals, that's just how mutating shared data works when using threading.

Note: global variables are the same thing as module-scope variables.

Martijn Pieters
  • 1,048,767
  • 296
  • 4,058
  • 3,343
  • I use WSGI. They aren't normally mutated doesn't mean it CAN'T be mutated. Since `a = Blueprint()` , but `a` can be changed on any request if the developer accidentally changed it. In some other languages like Go or C++, an instance like this must be declared inside a request/singleton or using mutex lock to make sure itsn't mutable – TomSawyer Apr 14 '19 at 13:17
  • @TomSawyer: WSGI is a standard, all Flask servers use WSGI. You configure your WSGI server to handle concurrency in different ways, threading is just one option. Python is a language that *trusts developers*, it doesn't generally put restrictions in place. – Martijn Pieters Apr 14 '19 at 13:18