From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,b1a7f997d8127c14 X-Google-Attributes: gid103376,public From: dewar@merv.cs.nyu.edu (Robert Dewar) Subject: Re: Too many tasks? overhead questions. Date: 1997/04/29 Message-ID: #1/1 X-Deja-AN: 238147999 References: <5jlkdu$rub@corn.cso.niu.edu> <01bc5256$1c9c4640$28f982c1@xhv46.dial.pipex.com> Organization: New York University Newsgroups: comp.lang.ada Date: 1997-04-29T00:00:00+00:00 List-Id: Robert Eachus said << Sure have a task for each player, but objects should be protected objects--they don't need their own thread of control. NPCs are an interesting issue, those pinned in a certain place should probably be treated as objects, those that wander the dungeon should have their own task or tasks. (Of course, if you have one task for all NPCs, make sure that NPCs don't try to interact...)>> Robert Dewar notes Be very careful about recommending the use of protected types. They are by no means a general abstraction mechanism (the abstraction is severely limited by the restriction on potentially blocking operations0. We have found a lot of users getting themselves into trouble, e.g. by doing a delay directly or indirectly in a protected operation, which is of course erroneous. It is clear that a lot of users (not surprisingly) do not understand this restriction. Unless efficiency is an overriding concern, it is better to use tasks for synchronization, since there you have no such concerns.