[dmd-concurrency] priority messages

[Michel Fortin]

Le 2010-01-25 à 11:29, Andrei Alexandrescu a écrit :

> 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.

I thought originally that you wanted to classify messages by priority, but that's not quite what you're proposing. You're proposing to be able to insert them in front of the queue. That's simpler than I was thought when you said "priority".

Perhaps "priority" isn't the right word, as to me it implies that "priority messages" would be scheduled still in FIFO order between themselves. That is not the case if you just insert on front, so perhaps we could use another name: "sendFront"?


> 2. "Must handle" messages that unblock any call to receive(). They may or may not have priority. These may be derived from Exception.

I'd say those should be just "tasks". Sending one would execute that task in the given thread, inside receive. Tasks could be shared delegates, functions, or structs and objects defining opCall.

For instance:

	void genericWorker() {
		while (1) receive();
	}

	auto soundThread = spawn(&genericWorker);
	soundThread.dispatch({ playSoundBlocking("hello.wav"); });
	soundThread.dispatch({ playSoundBlocking("world.wav"); });
	soundThread.dispatchFront({ throw new Exception("Don't play any more sound. Thanks."); });



> It's never simple is it :o/.

Looks simple to me now. ;-)

Two functions to send messages:  send & sendFront.
Two functions to dispatch tasks: dispatch & dispatchFront.

I think with that we have all the primitives we might need on the sender end.


-- 
Michel Fortin
michel.fortin at michelf.com
http://michelf.com/