Hi,
> > So, just to make sure I understood you correctly:
> > If A < B means that thread A spawned thread B, then, if indeed A < B
> > holds, sending a message to B would interrupt both A and B, sending A to
> > sleep and making B process the message, causing it to implicitly wake up A
> > again when it has finished processing?
>
> No - A processes the message sent to B while B goes on with whatever it's
> doing.
OK, thanks for clearing that up.
> > > 2. When a message is sent or posted, it disappears somewhere into Windows,
> > > which then makes the thread creator call the message handler of the spawned
> > > thread to process the message. As for when this is done, I have little idea,
> > > as while there I did declare and define a 'check for messages' message loop
> > > in the main process of my test app, I did not do it in the threads. The
> > > message loop in the main process was not handling the messages to the
> > > threads I created either. So the threads must have relied on Windows which
> > > provided a built-in message loop which jumped in to action whenever there
> > > was a message waiting.
> >
> > What were you doing in the threads? Just looping randomly, or doing system
> > calls of sorts?
>
> Hopefully this is covered in my example above.
Almost, but not completely: What was the main thread doing during that
time?
> > > However, if we wish to control this by always
> > > defining a message loop, we can.
> >
> > And this would guarantee us that all messages would be processed exactly
> > at the point we do the loop?
>
> Yes, we can use PeekMessage() to see if there is a message waiting, and if
> there is we can do something about it.
So is there a ProcessMessage() (or whatever) API function we can use if
PeekMessage() returns that a message is waiting? Also, since threads seem
to be interrupted in whatever they're doing to process messages sent to
their children, what are the conditions for such an immediate (rather than
PeekMessage()able) interruption? (for PostMessage() like message passing).
> > I don't see what's so bad about using sleep()- as you pointed out, it's
> > an elegant method not to cause 100% CPU usage. Is there some
> > platform-specific issue I'm missing here?
>
> Just that it's a loss of timing that we don't need, and can get around
> (probably).
Hmm, how so?
> > Hmm, where is the periodic processing of MIDI data in this model?
>
> I'm not sure how this currently happens in the program - does the current
> sound server ask for data every so often? If we alter the model to use our
> own message loop, we could put that in to occur every so often.
Right now, the sound server never asks for data, it is sent everything it
needs (song information etc.) and does the following:
while (true) {
t := calculate-time-to-next-note();
sleep-and-handle-messages(t);
play-next-note();
}
This handles concurrently to what the main process does. During the
sleep() call, the OS usually returns to the main process, from which it
returns to the sound server if the main process sleeps or has used up his
time slice (and other processes' demands have been met).
All of the switching between sound server and main program happens
implicitly; we trust the OS to do this.
> If the main process isn't what is getting the commands, then no. If the
> sound server is getting commands and midi data from resources,
This is what's happening, and it's impossible to do it any other way
without doing very painful timer handling all over the code in unrelated
program fragments, i.e. by emulating pre-emptive multitasking manually.
> then we would
> have to have some sort of model that builds in a message loop,
What do you mean by a message loop here?
> and perhaps
> spawns off CPU-intensive tasks in threads.
There no CPU-intensive tasks in the sound server that I'm aware of.
> Or maybe two threads that check
> for commands and data as well as spawned-off threads that process it. These
> spawned-off threads would then send messages back to the server. Actually,
> this is starting to sound more and more like a polled server - where do
> events come in again?!
Let's not overdo it with the multithreading- madness lies down that road.
Anyway, what we have right now is, indeed, a polled server. While the
'polling' part could be taken care of by some sorts of messages, what
we're always going to have is a separate program running asynchronously to
the interpreter which accepts commands from the main program and sends
back status information, either by explicit poll (current model) or when
it's time to send this information (Sierra SCI on IBM PC model).
> > > The problem is, if the code gets in and usually works, it's a lot
> > > easier to just leave it without cleaning it up, commenting it well,
> > > and going over it to check 'that one more time' for mistakes.
> >
> > Not if it just works 'usually'. Someone will take offense eventually and
> > give the code its deserved beating. However, there's always the risk of
> > old, unsafe and ugly code being forgotten if it works fine.
>
> Or if the code has been in there for a while and it's nasty and badly
> commented, people are less likely to want to fix it or may introduce bugs
> when attempting to improve it.
Well, IMHO code being nasty is an incentive for fixing it. You're right
though- people often prefer to fix bad code that they should rather be
re-implementing.
> > I know that the idea of good code being as easy to read as a comment
> > fails to work from time to time, at least in the world of imperative
> > languages. Therefore, I'd suggest this: Send me a list of places where you
> > think comments would be in order in my code- it's always easier to
> > poinpoint those places if you aren't the one responsible for the code- and
> > I'll add those comments and try to get used to a more commented coding
> > style this way.
> > How about it?
>
> Sounds good to me! And anyone else as well that notices something... One of
> the things I have trouble with is that while I realise there is an SCI spec,
> there doesn't seem to be a FreeSCI spec that I can find which explains how
> things within FreeSCI interface with each other and work.
Section 7 in the online docs documents basic differences between Sierra
SCI and FreeSCI, the functions provided by our built-in debugger,
savegames, and information neccessary for implementing kernel functions
(not updated for recent changes in resource management, though).
It is missing:
1. Documentation for the sound subsystem
2. 80% of the gfx subsystem documentation that _should_ be there
3. Our platform-independant tools.c functionality
4. A short introduction to the core header files and some information that
maps functionality to C files
I don't think there's much of a point in describing the program flow in
general, since that's not much other than "initialize", "load game", "run
game", and "uninitialize".
I think doing 3 and 4 would be most important. 1 might be about to change
somewhat anyway, while 2 is of little interest to most people
(apparently) and would require a lot of work to be finished.
I'd volunteer for 4; 3 would be mostly a summary of the resource.h
and sciresource.h header files, though.
For 3, it might be helpful to just create documentation from our headers
automatically. Does anybody happen to know of a good C syntax parser for a
decent high-level programming language?
(note to self: <!ENTITY foo SYSTEM "foo.sgml"> &foo;)
llap,
Christoph
