From: mentalg@geocities.com
  To  : GGI ML <ggi-develop@eskimo.com>
  Date: Wed, 9 Sep 1998 19:21:34 -0400 (EDT)

Re: SYNC mode should go

On Wed, 9 Sep 1998, Steve Cheng wrote:

> On Wed, 9 Sep 1998 mentalg@geocities.com wrote:
> 
> > I've been beating my brains out over the past week or so trying to come up
> > with a decent thread-friendly locking scheme that would be consistent with
> > and with USE_THREADS and didn't break the signal implementation of mansync
> 
> 
> > (or vice versa), and while I sort of worked out an API with both a
> > signal-friendly intlock/sigmask locking implementation and a pthreads
> > implementation, it's still a pretty ugly and inconsistent solution.
> 
> Please don't bother...

Already did :)  But that doesn't mean we have to use it.

> By the way, how is your code like so far?  I've been thinking that we should
> have generic (recursive) locking functions like
> 
> ggiLock(ggi_mutex *m)
> ggiUnlock(ggi_mutex *m)
> ggiTryLock(ggi_mutex *m)
> 
> #define ggiLockVis(vis)	ggiLock(vis->mutex);
> /* ... */

That's what I did, basically.  same prototypes, but called
ggiMutex{Lock,Unlock,Trylock} -- otherwise, same idea.  I was am trying to
cram the lock-deferred ggiFlush() logic that Steve and I discussed in there
too. (i.e. ggiFlush() during the lock causes the flush to be deferred until
the visual is unlocked -- proved to be more complex than I had expected)

Actually, I have ggiLock{Lock,Unlock,Trylock} for "recursive mutexes" (yes,
portably implemented), and ggiMutex{Lock,Unlock,Trylock} for normal mutexes.  
Not sure which one is more appropriate for locking visuals yet.  Performance
issues v.s. convenience/race/deadlock issues.

> > When porting old DOS apps to Linux, it works much better to stick calls to a
> > flush() function in appropriate places in the code, rather than take the
> > (somewhat considerable on some targets) performance hits of madly flushing
> > to give the illusion that the framebuffer is actually attached to the video
> > HW directly like it was in DOS.  Doing the little bit of rewriting necessary
> > to get the flush()es in there needs to be done anyway, as it also forces you
> > to clean up other issues in the process.  It also yields better performance
> > from the get-go, especially as you'll have to be emulating a lot of other
> > stuff anyway.  I speak from experience here.
> 
> Just wondering, besides SVGAlib, any other graphics libraries that always
> provide sync mode?

Well, if the code you're porting expects to be manipulating a raw EGA
textmode framebuffer :)  If it weren't for framebuffers, we wouldn't need
mansync; we would only need a ggiFlush() in libggi/stubs.c after every entry
point in sync mode. (not that that's really so good either)

-=MenTaLguY=-