[open-beos-printing] Fwd: [openbeos] Re: [Haiku-commits] Recursive processing of BLooper messages

Anfang der weitergeleiteten E-Mail:


Von: Ingo Weinhold <bonefish@xxxxxxxxxxxxxxx>
Datum: 03. Februar 2007 15:06:46 GMT+01:00
An: haiku-commits@xxxxxxxxxxxxxxxx
Kopie: openbeos@xxxxxxxxxxxxx
Betreff: [openbeos] Re: [Haiku-commits] Recursive processing of BLooper messages 
Antwort an: openbeos@xxxxxxxxxxxxx


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: