Friday, March 03, 2006

Evaluator classes, thread control

Evaluator classes receive user input and decide what to do with it. Active evaluator objects sit on a stack in the Env object and together comprise a large part of the user session state.

The bottom evaluator in the stack is always CmdEvaluator, and its job is to parse command lines from the user and invoke the appropriate command.

Conversly, the help and register commands (register is now working) invoke the HelpEvaluator and RegisterEvaluator respectively.

An evaluator is a state machine. It is responsible for any complex interactions with the user. It can do anything a command can do, but it can't display anything directly because it is not specific to any particular portal. For displays, commands and evaluators must invoke a view object which knows how to communicate with the portal.

Why do we have commands? Because commands are easier to code, and most commands are simple. Normally a command just parses the command line for arguments and performs some operation on the Ark or invokes some view. Usually there is no need for a state machine to manage this.

. . . . .

Now the Ark is intended to operate in an environment with either many readers (query commands running on multiple threads) or a single writer (an update command). Commands all declare themselves as being either query (the default) or update. It is the evaluator then that is responsible for thread control. In the case of CmdEvaluator, it must look at the command to determine if it is a reader or writer and handle thread control appropriately.

Note that while the Ark and the commands are inside thread control (this keeps them simple), everything else is outside thread control. But Env and the evaluators are unique to a single user session, and should be single threaded as a result--that's the portal's responsibility.

One of the catches to using evaluators instead of commands is that they are outside of code control and must manage it themselves. This adds considerably to the risk of having bugs in an evaluator. Fortunately most things can be done using a command.

. . . . .

I think it is time I start looking at thread control. We already have 3 evaluators which will need to be updated so that they properly manage thread control. Its time.

Bill

0 Comments:

Post a Comment

<< Home