[Bf-committers] Re: listener object

[Martin DeMello]

On 5/11/05, Stephen Swaney <sswaney at centurytel.net> wrote:
> 
> Blender is essentially single threaded. ( yeah, I know, the rendering
> threads... ) Scripts do not run in their own thread.
> 
> Think of blender as a database with multiple clients - the Spaces
> acting as browsers/editors.  Each Space has its own event queue
> and its own view of the data.  Locking and concurrency issues are
> controlled by using a single thread of execution.
> 
> This is one reason Ton had problems with the bpy Window module
> accessing events in other spaces.  Note that recent work by Willian
> has make it possible to bind a script to a Space.

How exactly does Window.QRead work, if there's no "the" event queue?
Is that one example of the "accessing events in other spaces" problem?

> If you want to do asynchronous I/O you have two choices:
> poll or wait on an event.  With a single thread, an event wait
> will lock the application and its UI.

That's the problem that motivated me to start this in the first place.
I figured I could have an entirely separate process waiting on
whatever event I wanted, which would then write to a socket, wake up a
python script that read the event data from the other process and did
whatever blender stuff it needed to. If scripts don't have their own
threads, this means that even multiple sockets triggering scripts will
only run them one at a time, right? Which, as I see it, puts the
responsibility back on the script writer not to write blocking
scripts, but doesn't raise a concurrency issue. Is there any
documentation you'd recommend as a starting point? Also, from the wiki
I see a proposal to "design a method for how Python scripts can be
attached to any Space type (probably by just becoming an event
handler!)" - is that what Willian's Space scripts do?

martin