[Bf-committers] Re: listener object

Stephen Swaney sswaney at centurytel.net
Wed May 11 14:35:23 CEST 2005


On Wed, May 11, 2005 at 05:44:22PM +0530, Martin DeMello wrote:
> Hi Douglas,
> 
> I was referring to the fact that the data coming over the socket
> server will never be relied upon, merely its presence or absence.
> Scripts will run in their own threads, yes, but don't they do that
> anyway? I was essentially hoping that the scriptlink mechanism already
> had safety guards in place to prevent the corruption of Blender data
> by multiple scripts trying to read/write it, which is why I said there
> shouldn't be any new concurrency issues introduced, but I'm rather new
> to Blender programming so I'm happy to be told where I'm going wrong.

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.

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.  

-- 
Stephen Swaney			
sswaney at centurytel.net



More information about the Bf-committers mailing list