[openbeos] Re: [Haiku-commits] Recursive processing of BLooper messages
- From: Ingo Weinhold <bonefish@xxxxxxxxxxxxxxx>
- To: haiku-commits@xxxxxxxxxxxxxxxx
- Date: Sat, 03 Feb 2007 15:06:46 +0100
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
Other related posts:
