On 4/7/07, skaller <[EMAIL PROTECTED]> wrote: > Just to make sure we understand: the worker queue is a neutral > synchronisation technique: there's a pool of threads which > pull jobs of the queue, run them, signal they're finished, > and then run the next one. The pool size is user controlled.
This is probably a dumb idea, but maybe instead of a fixed pool and a queue, forget the queue and just have a pool that dynamically resizes itself when all the worker threads are busy. Reclaim worker threads that have been inactive for so many seconds. Since fthreads block on I/O the pool size will be bounded by the number of fthreads. Of course, if the user spawns a thousand fthreads and has each of them perform some I/O operation, we'd end up spawning (temporarily) a thousand worker threads, the effects of which would vary system to system. (My warning to a user would be "don't do that!" :)) Returning to the (admittedly more sane) idea of using a queue... > To make it seem more 'intuitive' that a queue really is > required, just consider fileio requests on your local > disk as opposed to an NFS mounted volume. NFS can be > very slow .. it makes sense to have TWO queues, > one for the local disk and one for NFS, to that the fact > thread A is waiting on NFS doesn't stop thread B doing a local > disk operation. I would argue that with multiple worker threads this wouldn't be much of a problem... thread B will only wait until *one* of the worker threads becomes available. Granted, they all could be tied up with NFS calls, but the probability of this decreases as you increase the maximum number of worker threads. - Chris ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Felix-language mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/felix-language
