[interfacekit] Re: :) Again - BBitmap

On Tue, 29 Jul 2003 21:22:52 +0300 "Adi Oanca" <adioanca@xxxxxxxxxxxxx>
 wrote:
[...]
> >
> > >     And... to reformulate my earlier question: Is it equal good 
> > > to
> > > have
> > > context switching at server side or at driver side? Isn't the one 
> > > at
> > > driver
> > > side more costly?
> >
> > I actually don't get what you mean by context switching on driver 
> > side.
> > If a thread from another team is scheduled, then a context switch 
> > is
> > done.
> 
>     But,... that's does not happen in app_server, all threads have 
> the same
> team.

Sure, but the threads of an application are in a different team. Hence 
there is at least one context switch between the invocation of a BView 
drawing method and the point when the actual drawing is finished. For 
synchronous requests there's at least another context switch before the 
application can continue.

> > For a syscall (including driver calls through ioctl()) only a
> > mode change is done.
> 
>     I'm talking about cloning accelerants. One for every application 
> that
> uses off-screen bitmaps. Every one of them, have to wait for a lock 
> from the
> driver. Isn't this context switching?

When the thread tries to acquire an already locked mutex, then it is 
descheduled and another thread is scheduled. If the new thread belongs 
to another team, then a full context switch needs to be done.

> Is it more good at driver side? 'Cause
> IHO, it isn't - if app_server were to draw in off-screen bitmaps, 
> then. no
> context switching would be done.

I'm not sure, if I understand your reasoning. Are you trying to say 
something like that, if all drawing is done by the app server, the 
system would only need to switch between those? That assumes, that 
virtually no other thread is ready to run at that time.

Anyway, I still don't think, cloning accelerants in the applications is 
a good idea. It undermines the client/server approach and will make 
implementing support for running remote applications more complex.

CU, Ingo

Other related posts: