Ho hum

[Ling]

On Sat, 12 Apr 1997, Nathan Yospe wrote:

> On Sat, 12 Apr 1997, Ling wrote:
>
> Hmmm. Did any of us provide personal life stuff?

Dunno, I thought I'd provide those snippets of information so you guys
know my leanings and background.  *shrug*  The main bit being untrained
which means I like to think I've got the aptitude and intuition for coding
but I don't know all the computer jargon (there's a distinct trend to name
and patent anything which moves).

> :Nathan:  How on earth does your intepreter conducts the risk assessment?
> :Eg:
> :> shoot rifle at tank
> :You sure?
> :> yes
> :You die but luckily it wasn't painful coz that one had the latest
> :vapouriser thingibob (manufactured by Grestel).
> :etc
> 
> You mean, how does it decide to ask "you sure"? That's pretty simple.
> There is a probability weight on prefered interpretation of a command,
> with comparative risk being a crude product of action effectiveness and
> consequences. This is part of the command interpreter, and is tied

I would have thought that'll be fairly tough to calculate.  Does it every
ask 'You sure?' when it's obviously a low risk action?

> :in reading through some of the old stuff.  Just thought I'd bring the
> :topic of game design back into the mailing list and pollute the optic
> :fibres with my presence whilst I'm at it.
> 
> Ah, now this is a fun debate. Personally, I like a system with feedback
> between a list of attributes and a list of skills, all of which are

Hmm.. I'll wait patiently for some development (like that Champion thing). 
Gonna be busy for the immediate future...


Earlier, someone mentioned the possibility of the processor spending most
of it's time time-slicing between multiple threads if there was a lot of
connections.  This number of threads business seems a lot like voodoo to
me and being the unsure vulnerable type (while I'm in this mailing list
watching all you masters chat), I won't mind some help.  This is my model
and it'll be great if someone commented (it's for a uniprocessor):

Initial thread:  Sets everything up, opens a socket, and waits to
		terminate.
Signal thread:  Sits in a sigwait() loop, handles signal for the entire
		process.
Server thread:  Waits for the next connection.
Input Socket thread:  Snoozes on select(), gets input from socket and
		plonks it in the input buffer, serves multiple sockets.
Output Socket thread:  Waken up whenever there's something in the output
		buffer.
Input processing threads:  Multiple threads which interpret the actual
		input, multiple meaning something like 1:10 ratio of
		threads to clients.
Event processing threads:  3 threads sat in a pool (nicked from Lambert's
		I think).
Area threads:  The usual, I've not thought about this yet, it's gonna pose
		a problem.
Compiler threads:  Compiles I suppose...


The main focus is on the socket threads.  I can either use the above or I
can:  Combine the socket input and output threads by getting the signal
handler to wait for SIGIO, use select() to figure out which client(s) have
input pending and use semaphores to tell the appropriate threads, the
socket threads would sit in a semaphore wait position (the semaphore can
be released by the signal handler or be an event which has just popped
something in the output buffer).

The dilemma is:  If I used select(), the socket threads will either have
to use a loop to check input and output buffers or I can have input and
output threads (the server thread can have SIGIO all to herself).  If I
depend on SIGIO, I will have to end up using select() anyway to figure out
which socket it was and I may as well have one thread sleeping on
select(), waking up the other threads when needed.  What gets me is that
if I used the later, won't there be an awfully high number of SIGIOs being
sent out?

*ponder*


PS: Thanx for the small bit of something about PCCTS, Jeff.

  |				"With my naked eyes I saw the falling"
_O_O_  Ling - Freshwater fish	 rain coming down on."