[Bf-committers] Wondering about the review of the command port patch...

Stéphane SOPPERA stephane.soppera at wanadoo.fr
Fri Sep 19 08:24:53 CEST 2008

> +/**
> +   busy waiting for new events.
> +
> +   Note: The blocking GHOST event processing is
> +   implemented in the same way using busy waiting (polling)
> +   on the GHOST event queue.  Doing the same on the Blender 
> +   event queue makes it possible to also react to events
> +   inserted into the Blender main event queue by parallel
> +   threads - for example the Blender command port thread.
> +
> +   Added to make the command port work :)
> +   (dietrich)
> +*/
> +static void wait_for_event()
> +{
> +	while (!mainqtest()) {
> +		PIL_sleep_ms(5);          /* sleep for 5 milliseconds */
> +		winlay_process_events(0); /* if there are events in the GHOST queue,
> +									 (non-blocking polling of GHOST events) 
> +									 preprocess them and copy them over
> +									 into the Blender main event queue.
> +								  */
> +	}
> +}

Instead of this busy waiting with a 5ms sleep, wouldn't it be better to 
use a pthread condition?

That would prevent this hugly busy waiting and enable any thread adding 
an event to break the wait on the condition and make the event loop 
handle the new message.
As far as I know this is the usual way to implement a blocking queue 
with pthread and it would make the process nicely sleep when no events 
are available. Moreover when events come fast and are handled fast, 
there would not be a sleep of 5ms between the handling of each event.

Finally, on windows, there is the PostMessage function that can be used 
to post a message on the events queue of a thread, and using a WM_USER 
message would be far easier than having to add a custom lock+condition. 
I don't know XLib programming, maybe there is the equivalent functionality.


More information about the Bf-committers mailing list