Return-Path: william@bourbon.usc.edu Delivery-Date: Thu Oct 2 19:57:54 2008 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on merlot.usc.edu X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.2.3 Received: from bourbon.usc.edu (bourbon.usc.edu [128.125.9.75]) by merlot.usc.edu (8.14.1/8.14.1) with ESMTP id m932vsPu000872 for ; Thu, 2 Oct 2008 19:57:54 -0700 Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1]) by bourbon.usc.edu (8.14.2/8.14.1) with ESMTP id m9332oQ4014702 for ; Thu, 2 Oct 2008 20:02:50 -0700 Message-Id: <200810030302.m9332oQ4014702@bourbon.usc.edu> To: cs551@merlot.usc.edu Subject: Re: final part 1 Date: Thu, 02 Oct 2008 20:02:50 -0700 From: Bill Cheng Someone wrote: > Design Question: > you have mentioned in the lecture that a good way > to keep a track of all timers is to maintain an universal timer which goes > of after every one second. > Is it a good idea to keep an alarm that goes off after every 1 second and > the signal handler will then decrement the various timers and take > necessary actions if the timers are decremented to 0? > > As the alarm keeps going off it will affect some blocking system calls like > recv() which can cause unforeseen errors. so should we use threads instead > of a signal handler which wakes up after every one second and those the same > work as the signal handler.? I think using an alarm to wake up every second is an overkill. You can just use a separate thread and have it wake up every second. This thread can also "scrub" all the data structures that need to be scrubbed (by decrementing each countdown counter by one and create events when a counter reaches zero). -- Bill Cheng // bill.cheng@usc.edu