[dmd-concurrency] priority messages
Kevin Bealer
kevinbealer at gmail.com
Mon Jan 25 08:36:03 PST 2010
Are you also considering multiple levels of priority? In the reader /
processor / writer case, I can think of several priorities the processor
might want:
1. Normal -- here is another buffer to write.
2. Medium -- the file read failed, stop with this file.
3. Medium#2 -- too much information too fast, please stop sending until
further notice.
4. High -- The system is going down, pack up and get out of dodge
I'm not sure if #2 and #3 need to be at different levels, but it seems like
1, (2 or 3), and 4 should be distinct. E.g. you don't care about either
Medium if there is a High in the pipe and you want to process Normals after
any High or Medium is handled.
This argues for a many-level approach, which might as well be an integer or
short.
Kevin
On Mon, Jan 25, 2010 at 11:29 AM, Andrei Alexandrescu <andrei at erdani.com>wrote:
> Michel Fortin wrote:
>
>> Personally I'd tend to just not define any priority and deal with
>> things in a FIFO manner to keep things simple. If you want to add
>> complexity (priority), it should be justified by use cases. So which
>> use case do you have in mind for priority?
>>
>
> Upon further thinking, I realized there's need for two orthogonal things:
>
> 1. Priority messages of any type. They'll be put to the front of the queue.
>
> 2. "Must handle" messages that unblock any call to receive(). They may or
> may not have priority. These may be derived from Exception.
>
> It's never simple is it :o/.
>
>
> Andrei
>
> _______________________________________________
> dmd-concurrency mailing list
> dmd-concurrency at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-concurrency
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/dmd-concurrency/attachments/20100125/6d79809c/attachment.htm>
More information about the dmd-concurrency
mailing list