[haiku-appserver] Re: communication
- From: Stefano Ceccherini <burton666@xxxxxxxxxxx>
- To: haiku-appserver@xxxxxxxxxxxxx
- Date: 6 Jun 2005 10:04:43 -0000
>I didn't go through that now, but actually, I don't think >it's
>necessary: that BAppServerLink uses the BApplication lock to
>synchronize its messaging just feels plain wrong to me :-)
As stippi just told me, the deadlock was inevitable as menus use their own
window(s), and having > 1 window within the same application would have exposed
the problem (fonts stuff use BAppServerLink, for example).
>I choose a simpler road for now, I just create a separate port on first
>try, and it'll be alive as long as the application itself.
>Since it doesn't lock the BApplication, and the reply is handled
>directly (it doesn't go over the BApplication's message loop), we
>cannot use the BApplication's reply port.
Yeah, I thought so.
> >Also, we should replace the almost useless SERVER_TRUE and >
> > SERVER_FALSE
> >with real error codes, a standard status_t will do here.
> Ahhh, yes, I want that too :)
>Okay :-)
I _think_ we can even do the transition without much trouble. I mean, just make
SERVER_TRUE = B_OK, SERVER_FALSE = B_ERROR and you don't even need to change
the definitions all at once around the server's code.
BTW, I think we could also split ServerProtocol.h within different headers (as
it has become really big), or at least split and reorganizate the definitions
in different enums.
There are, in there, also "private" app server defines which should go in
another file, IMHO.
just my 2 (euro) cents.
Stefano Ceccherini aka Jack Burton
---------------------------------------------------------------
Scegli il tuo dominio preferito e attiva la tua email! Da oggi
l'eMail di superEva e' ancora piu' veloce e ricca di funzioni!
http://webmail.supereva.it/new/
---------------------------------------------------------------
Other related posts:
