March 08, 2010 [dmd-concurrency] std.concurrency | ||||
---|---|---|---|---|
| ||||
Posted in reply to Igor Lesik | On Feb 24, 2010, at 12:29 AM, Igor Lesik wrote:
> Sean, I think your implementation of receive() has some imperfections, which I fixed and it works now all right.
>
>> Most importantly, this still doesn't work: receive( (int a) {}, (string b) {} );
>> The compiler still "sticks" on the type of the first delegate in the foreach ...
> That is very true, but we can iterate over T instead of ops, which is even better idea.
>
>> Once this is fixed I'll add checking for overload conflicts in the receive set, etc.
> "receive( (int a) {}, (string b) {} );" works now, we can continue
Okay, I checked in the first cut of this module. It still lacks receiveTimeout and receiveOnly, but plain old send/receive are in place. I'll see about improving it over then next N days.
|
March 09, 2010 [dmd-concurrency] std.concurrency | ||||
---|---|---|---|---|
| ||||
Posted in reply to Sean Kelly | >Okay, I checked in the first cut of this module.? It still lacks receiveTimeout and receiveOnly, but plain old send/receive are in place.? I'll see about >improving it over then next N days.
Excellent, thanks.
Please, consider an idea to check if first parameter of receive() is not delegate but integral and treat it as timeout value. It makes both receiveTImeout() and receiveOnly() one liners.
|
March 09, 2010 [dmd-concurrency] std.concurrency | ||||
---|---|---|---|---|
| ||||
Posted in reply to Igor Lesik | On Mar 9, 2010, at 1:49 AM, Igor Lesik wrote:
>> Okay, I checked in the first cut of this module. It still lacks receiveTimeout and receiveOnly, but plain old send/receive are in place. I'll see about >improving it over then next N days.
>
> Excellent, thanks.
>
> Please, consider an idea to check if first parameter of receive() is not delegate but integral and treat it as timeout value. It makes both receiveTImeout() and receiveOnly() one liners.
Will do.
By the way, I've been thinking about receive((int x) {}, (Variant x) {}) and I wonder if rather than testing the first element in the queue and having the Variant delegate getting the value if it's not an int, that the correct behavior should perhaps be to search the entire queue for an int and if there aren't any then take the first element and give it to the Variant. I suppose it would be easy enough for the user to imitate with two consecutive receives, the first having a 0 timeout though.
|
March 09, 2010 [dmd-concurrency] std.concurrency | ||||
---|---|---|---|---|
| ||||
Posted in reply to Sean Kelly | >By the way, I've been thinking about receive((int x) {}, (Variant x) {}) and I wonder if rather than testing the first element in the queue and having the Variant delegate getting the value if it's not an int, that the correct behavior should perhaps be to search the entire queue for an int and if there aren't any then take the first element and give it to the Variant.
Consider receive((int x){},(string s){}), first element in the queue is string, do you search for int in the whole queue in this case? No, you search for a handler for string. Case receive((int x) {}, (Variant x) {}) is not (and should not be) different. With what you propose user will experience very non deterministic behavior with messages processed completely out of order; consider long queue [var, string, ..., int] with int at end, why on earth user wants last element in the queue to be handled first?
Plus it will mess up msg priorities, in case we implement them one day.
|
March 09, 2010 [dmd-concurrency] std.concurrency | ||||
---|---|---|---|---|
| ||||
Posted in reply to Igor Lesik | On Mar 9, 2010, at 9:50 AM, Igor Lesik wrote:
>> By the way, I've been thinking about receive((int x) {}, (Variant x) {}) and I wonder if rather than testing the first element in the queue and having the Variant delegate getting the value if it's not an int, that the correct behavior should perhaps be to search the entire queue for an int and if there aren't any then take the first element and give it to the Variant.
>
> Consider receive((int x){},(string s){}), first element in the queue is string, do you search for int in the whole queue in this case? No, you search for a handler for string. Case receive((int x) {}, (Variant x) {}) is not (and should not be) different. With what you propose user will experience very non deterministic behavior with messages processed completely out of order; consider long queue [var, string, ..., int] with int at end, why on earth user wants last element in the queue to be handled first?
>
> Plus it will mess up msg priorities, in case we implement them one day.
Yeah, it was just and idle thought.
|
Copyright © 1999-2021 by the D Language Foundation