FreeLists / openbeos / [openbeos] Re: [Haiku-commits] Recursive processing of BLooper messages

[Ingo Weinhold <bonefish@xxxxxxxxxxxxxxx>]

On 2007-02-03 at 13:00:53 [+0100], Michael Pfeiffer 
<michael.pfeiffer@xxxxxxxxx> wrote:
> 
> I do not know how to solve the following problem:
> 
> 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?

I had a look at the always handy R5 libbe objdump: BPrintJob::ConfigPage() 
itself doesn't seem to do anything suspicious (e.g. some BMessage access 
methods), but it calls three other functions:

* 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.

> PS: Cross-posting to get more attention. Please reply to open-beos-
> printing@xxxxxxxxxxxxx if possible.

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