Recursive processing of BLooper messages

Michael Pfeiffer

2007-02-03 14:58:34 UTC

Datum: 03. Februar 2007 15:06:46 GMT+01:00
Betreff: [openbeos] Re: [Haiku-commits] Recursive processing of
BLooper messages
On 2007-02-03 at 13:00:53 [+0100], Michael Pfeiffer

Post by Michael Pfeiffer
In BeOS R5 you can call BPrintJob.ConfigPage() inside a BLooper hook
method and although the method ConfigPage() did not return yet, the
calling BLooper still is processing messages sent to it.
In the Haiku implementation of ConfigPage(). A synchronous message is
sent to the print_server, the print_server then opens the dialog and
when the dialog is closed it sends a response. ConfigPage() handles
the response message and returns. Of course this blocks the calling
thread.
In case the calling thread is a BLooper thread. My idea is to do the
communication with the print_server in a separate thread. In the
meantime ConfigPage() keeps processing the messages sent to the
BLooper until the spawned thread terminates.
What are your thoughts? How can the nested processing of messages be
accomplished? Are there other ways to do that?

BPrintJob::ConfigPage()
itself doesn't seem to do anything suspicious (e.g. some BMessage
access
* do_async_print_panel(): Creates and runs an asynchronous BAlert.
Creates
a semaphore and spawns and resumes a thread. Furthermore there're
invocations of BLooper::LooperForThread(long), dynamic_cast<>(),
BWindow::UpdateIfNeeded(), and acquire_sem_etc(). The spawned thread
executes async_print_panel_hook(), which constructs a BMessenger
(signature
version), creates and runs a synchronous alert, sends a synchronous
message, and invokes delete_sem().
* BPrintJob::GetCurrentPrinterName(void): Constructs a BMessenger
(signature version) and sends a synchronous message. There's a bit of
BMessage access, too, but that's it. Nothing asynchronous.
* BPrintJob::HandlePageSetup(): Apparently just analyzes the supplied
BMessage.
I haven't gone through the pain of analyzing the control flow -- so
not all
of the stuff listed above might always be executed -- but it looks
like
things pretty much happen as you had in mind: At least some
synchronous
messaging is done in a separate thread, while the original thread
seems to
check whether it belongs to a BWindow and calls
BWindow::UpdateIfNeeded()
(probably in a loop), the threads being synchronized via a
semaphore. You
probably know best what the BAlerts are for.

Post by Michael Pfeiffer
PS: Cross-posting to get more attention. Please reply to open-beos-

I'm not subscribed to the printing team list, since I'm not that much
interrested in that area, so I'm replying on the commit list again,
cross-posting to the main list, which, I believe, is a more appropiate
place.
CU, Ingo