From: Jon M. Taylor <taylorj@ecs.csus.edu>
  To  : ggi-develop@eskimo.com
  Date: Thu, 10 Sep 1998 14:56:17 -0700 (PDT)

Re: SYNC mode should go

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.
> 
> Honestly, we should really drop SYNC mode...

	I disagree.  It should be deemphasized, yes, but not completely 
removed.  It is convenient in certain situations.
 
> Why is it there?  To allow programmers who picked up odd habits in DOS to
> feel more at home?

	Mostly.  It is also an easy way to set up a generic flushing
system when you are developing a target which will need tuned flushes.  I
would not have been able to get the Glide target back on its feet as
quickly as I did without being able to lean on the mansync helper.  The 
flushing is suboptimal (the filled boxes in demo.c update like three 
times |->), but now I can tweak the flushing at my leisure and I have a 
working system.

> We take a performance hit/bloat increase for it, although the shared mansync
> stuff has mitigated the bloat a lot, and the performance hit is only if you
> actually USE it...

	Right.
 
> It really really makes any sort of consistent/correct locking scheme really
> painful to design/implement if you use the mansync signal implementation.

	Right again.  mansync is a hack, but it does come in handly in 
places.  It is not meant to be a permanent solution.

> The signal mansync implementation also screws with your SIGALRM handlers.  

	That is not good.

> Mansync should be handled by the application if it's really that important
> (if you _must_, it would be a good candidate for a separate utility library,
> but just provide a function to get called from the app's own signal handler
> in that case). I really dislike libraries taking over signals, especially to
> implement something I'm not going to use anyway.

	Not a bad idea.  And it would make it easier to have the
application spawn the flusher as a thread that would block until SIGALRM.
 
> 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.  

	But in this curcumstance it is *very* nice to be able to use a 
QuickHack(tm) like mansync to get a suboptimal-but-working display flush 
right away.

> 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.  

	Having to do optimizing on a system that A) you may be unfamiliar 
with and B) must work in order for your app to display anything can be a 
large turnoff.  Being able to start off with a simple timer-based flusher 
like mansync greatly eases that transition.

> 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.

	At the beginning of a port, IMHO the first priperity is getting 
something up and running, not optimizing.
 
> No matter which way you hash it, SYNC mode just encourages/requires bad
> code.  It should go.  

	I disagree, IMHO.

> LibGGI (and certainly some of the underlying target
> implementations) doesn't seem to really be async-signal-safe anyway, so the
> signal-based mansync is kinda dangerous...

	Of course there are improvements that are needed.  Perhaps even 
fairly large ones.  But IMHO the basic idea of a simple timer-based 
flusher is works keeping around as an *option*.
 
> Hrm.  I wonder if signal mansync is responsible for the weird Xlib failures
> that looked like multithreading problems I've experienced in the X target in
> the past when I wasn't using threads...

	I thought that came from not having threadsafe X libs?

Jon 

---
'Cloning and the reprogramming of DNA is the first serious step in 
becoming one with God.'
	- Scientist G. Richard Seed