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

Anfang der weitergeleiteten E-Mail:

> Von: Ingo Weinhold <bonefish-CFLBMwTPW48UNGrzBIF7/[email protected]>
> Datum: 03. Februar 2007 15:06:46 GMT+01:00
> An: [email protected]
> Kopie: [email protected]
> Betreff: [openbeos] Re: [Haiku-commits] Recursive processing of  
> BLooper messages
> Antwort an: [email protected]
>
>
> On 2007-02-03 at 13:00:53 [+0100], Michael Pfeiffer
> <[email protected]> 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-
>> [email protected] 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
>
>