On Fri, Sep 20, 2002 at 01:38:44AM +0200, Christoph Reichenbach wrote:
> Does the new design explicitly assume the presence of threads to be able
> to function at all, or could someone eventually implement a forked sound
> server without using shared memory, by fitting into the current interface?
My new "design" assumes you have full shared memory space. This could
be faked via shm, but it could be painful, and probably just as
reliable/portable as threading.. :)
fundamentally, I want all of the bookkeeping/state and "control" stuff
of the current soundserver moved into VM context. Only the note loop
goes in the "forked" part, and it's controlled by global (and/or shared)
variables.
My current design uses a shared memory queue to pass back ccc changes
and signals. How that queue is polled (explicitly by the script, as in
SCI1, or implicitly by the VM, like we're doing now) doesn't matter.
I'm not bothering to write directly to the heap ATM, as the current
queue implementation requires no synchronization/locking. :)
With this in mind, it's certianly possible to keep a fork()-based
soundserver. But it'll be a bit painful..
Anyway. Now I'm off to experiment with a pcmout-timer-driven
adlibemu-specific soundserver. It'll be worthless for real MIDI output
though.
- Pizza
--
Solomon Peachy pizza@f*cktheusers.org
I'm not broke, but I'm badly bent. ICQ #1318344
Patience comes to those who wait. Melbourne, FL
Quidquid latine dictum sit, altum viditur
-- Attached file included as plaintext by Listar --
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQE9imnIPuLgii2759ARAohIAJ9mruMSFmbXBzK3rrwquacSYfFu3wCePK7V
uiHW9P9psyB/gkh/x4t+JnU=
=/kdz
-----END PGP SIGNATURE-----
