111CMSC 212 – S07 (lect 20)AnnouncementsProgram #4 – Due Tomorrow morning– Extension becuase Scary was down last night– Baby is back up – use linux.grace.umd.eduProgram #5 on the Web later todayReading– Notes (Today)– Bryant & O’Hallaron 10.10 (Tuesday)2CMSC 212 – S07 (lect 20)Project #5Two Goals– Implement a tree API– Develop test cases for itGrading– Do your test cases find bugs?• We have many buggy versions of the API• Will your tests report bugs when encountered– Do your tests have good code coverage?• Score for % of lines in your implementation that your tests cover– Private tests for correctness of you API implementation– multiple parts• tests of our implementation with your test cases• tests of your implementation with our test cases• tests of your implementation with your test cases– Start by writing test cases (for the public points)• but you will probably find you want to do it concurrently223CMSC 212 – S07 (lect 20)EventsMany programs need to respond to external activity– keyboard– mouse– network– sensorsMany programs can expect input from multiple sources– often don't know where the next input will come– will the user press a key or move the mouse next?Events are a way to represent these activities– can also includes other things (such as timer alarms)4CMSC 212 – S07 (lect 20)Event Driven ProgrammingProgram consists of a main loop waiting for eventsDefine set of functions to handle each event– process event, and then returnOften uses function pointers to define events and their handlers335CMSC 212 – S07 (lect 20)Structure of an Event Driven Programwhile (1) {event = getNextEvent();switch (event.type) {case MOUSE_EVENT:processMouse(event));break;case KEYBOARD_EVENT:processKeyboard(event);break;…..}}6CMSC 212 – S07 (lect 20)Handling Multiple Events - SelectOften events are coming from file descriptors– keyboard input– file I/O– network communicationSelect system call– blocks waiting for I/O to be ready on a set of file descriptor– returns when one or more file descriptors have I/O ready– does NOT perform the I/O– can include a timeout• prevent blocking forever• allows time based events447CMSC 212 – S07 (lect 20)Select System Callint select(int n, fd_set *readfds, fd_set *writefds, fd_set *exceptfds, struct timeval *timeout);– n - highest numbered file descriptor in any set– readfds, writefds, exceptfds - sets of file descriptors– timeout - how long to wait for events– return • value is number of descriptors in sets• sets modified to indicate which file descriptors are activeset routines– FD_ISSET(int fd, fd_set *set);• returns integer indicating if fd in the set– FD_SET(int fd, fd_set *set);• added fd to set– FD_ZERO(fd_set *set);• clear out the set8CMSC 212 – S07 (lect 20)Why select for writing?Why select for writing?– Output buffers have finite size.• All communication fd's have buffered output.– To keep devices busy while application does something else.– write() ordinarily blocks if buffer is full; waits for drain.– Easy for select() to tell if there is space.– So it makes sense to select() for writing.Why select for errors?– learn about I/O problems– learn when a network connection closes down559CMSC 212 – S07 (lect 20)Select Exampleint main() {int ret, myServerFD, maxFD = 0; FD_SET set;myServerFD = connectToServer();while (1) {FD_ZERO(&set);FD_SET(0, &set);FD_SET(myServerFD, &set);if (myServerFD > maxFD) maxFd = myServerFD;ret = select(maxFd+1, &set, NULL, NULL, NULL);if (ret) {if (FD_ISSET(0, &set)) { /* read from standard input */ }if (FD_ISSET(myServerFD, &set)) { /* read from net */ }}}}10CMSC 212 – S07 (lect 20)Handling I/O EventsReading from Standard inputvoid readStandardIO() {ret = read(0, line, sizeof(line));/* process line */}6611CMSC 212 – S07 (lect 20)Coordinating EventsSometimes Events come from sources other than file descriptors– other threadsSolution:– use a queue of events– threads wishing to communicate en-queue eventsmain loop for event queue paradigm:while (1) {event = myEventQueue->dequeue();/* process event */anotherEventQueue->enqueue(response);}12CMSC 212 – S07 (lect 20)How do event-driven programs maintain state? Ordinary programs, and threads, use variables on the stack.– Thread's stack persists across thread context switchesEvent-Driven programs can't keep state on the stack. – Since each callback must return immediately. – We want to associate data/state with each callback.Solution:– Keep data in heap allocated structure– associate structure instance with file descriptor– can include functionPointer+arg• function pointer defines what to call• arg defines state for that function7713CMSC 212 – S07 (lect 20)How to Keep Programs ModularProblem:– Multiple parts of the system want to process events– Everyone wants to write to a main loopSolution:– Define an interface to allow event handlers to register– Single common event loop– Callback functions to specific event handlers14CMSC 212 – S07 (lect 20)Example Using Callbackstypedef int (*handlerFunc)(int fd, void *arg);typedef struct {handlerfunc handler;int fd;void *arg;}
View Full Document
Unlocking...