[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.
> + */
> + }
> +}
>
Hi,
Instead of this busy waiting with a 5ms sleep, wouldn't it be better to
use a pthread condition?
http://www.humbug.org.au/talks/pthreads/pthread_cond.html
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.
Regards,
Stéphane
More information about the Bf-committers
mailing list