nanogui: Suggestion for adding nanowm into graphic server!
Subject:
Re: [nanogui] Re: Suggestion for adding nanowm into graphic server!
From:
####@####.####
Date:
8 Aug 2002 10:10:40 -0000
Message-Id: <OF1A5698A3.9F20CF7A-ON80256C0F.0031DC2C@diamond.philips.com>
Alex wrote:
> Aaron J. Grier wrote:
> > one of the outstanding core issues on my nano-X wishlist is to make it
> > fully reentrant. it seems like anything else involving clever hacks to
> > link multiple tasks into the server is just sidestepping this issue.
> > there are plenty of embedded systems without virtual memory where a
> > reentrant nano-X would be a big win.
>
> I think that's easier said than done. Allowing multiple threads in the
> server would need locks sprinkling all over the place. Anywhere the
> screen is drawn to probably (to avoid two threads drawing on the same
> part of the screen at the same time), and anywhere shared resources such
> as windows and pixmaps are accessed (to make sure one thread can't
> destroy them while they're still being used by another). Which leaves
> you without a whole lot of stuff that _can_ safely be done by two
> threads at once. It's not like in an OS kernel where one thread can
> safely talk to a disk controller while another talks to a network card.
One place where concurrency would be useful is event handling. It's
good to be able to have one thread waiting for events, while another
draws to the screen. (It is possible to kludge this at the moment, but
a documented way to do it would be good).
But I don't think we need fine-grained locking, since that's only a win on a
multiprocessor system. Having two main locks would be fine - one to
guard the GrGetNextEvent() family of calls, and one to guard absolutely
everything (including GrGetNextEvent()) except for the actual select() call
in GrGetNextEvent().
It would be great if the locking was supported in both client/server
and LINK_APP_INTO_SERVER modes.
> Another question: what "flavour" of OS threads would be guaranteed to
> work on both Linux and all the embedded systems we might want to run on?
> Pthreads?
Pthreads is probably the most portable option. It might be worth hiding the
actual lock and unlock behind #defines, so they can be changed easily.
Also, some platforms don't have recursive mutexes (i.e. if the same thread
attempts to lock a mutex twice it deadlocks), so it would be good to avoid
them. (A non-recursive mutex can be implemented as a simple binary
semaphore, and that's going to be supported on almost all platforms.)
Kind Regards,
Jon Foster
