Stefano Ceccherini <burton666@xxxxxxxxxxx> wrote: > >do so this way. But before we change this, we should probably > >investigate in the exact cause of the deadlock. > Ok, agreed. 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 :-) > Yeah, there was a small discussion some weeks ago on the list. I must have missed that one. > What about using a static reply port here too ? It would be managed > by the > static lock, so it shouldn't run into concurrency problems. > We would create it when BApplication calls InitData(), and destroy it > when the > BApplication dies. > Or we could use the BApplication's reply port (as Adi suggested in > the > mentioned discussion). But I don't know if it's feasible. 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. > >Furthermore, the message code > >alone need to carry infos like "needs reply". > >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 :-) Bye, Axel.