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

SYNC mode should go

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

Why is it there?  To allow programmers who picked up odd habits in DOS to
feel more at home?

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

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

The signal mansync implementation also screws with your SIGALRM handlers.  
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.

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.

No matter which way you hash it, SYNC mode just encourages/requires bad
code.  It should go.  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...

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

-=MenTaLguY=-