4 ms·

Can someone correct me if I am wrong. But why do I feel like promises are basically just semaphores in disguise? I'm a big fan of semaphores, that being said I

by seivan 14y ago

Can someone correct me if I am wrong. But why do I feel like promises are basically just semaphores in disguise? I'm a big fan of semaphores, that being said I am aware of how many people shoot themselves in the foot. It requires discipline. Have a couple of asynchronous operation queued behind each other? Setup a semaphore before each one. Signal when previous operation is done. Could have different semaphores for fail and success operation even.

awj 14y ago
They are, but in a similar way to how objects are basically just structs in disguise. You can use semaphores to build promises, but like all other abstractions it's better to have it be shared amongst all the code you use. The "get the result of this computation or tell me when it ends and maybe tell me about progress" pattern is common enough that it might as well get written once and be a generally available tool.
- seivan 14y ago
  True. Going to look if I can build a generic way of doing promises via semaphores in obj-c so the code base follows the same pattern overall. Just for fun, I suppose there are already better solutions out there. But none of them use signals.
Strilanc 14y ago
The concepts are similar. However: - Promises don't block the caller. You don't wait, you provide a method to call on completion. - 'Signaling' a promise (completing it) causes all callbacks to run, instead of just one. - Promises never transition from completed to not-completed. They settle. - Promises naturally propagate values. Semaphores can be useful for implementing a promise, but they're not quite the same.
- seivan 14y ago
  1) Yeah I guess that's what semaphores are for, but the way to mitigate that is to block in a different queue. :-) Not saying this is the right way, I am saying this is part of me refactoring deep nested blocks. It's the middle ground before doing it properly. 2) Not sure what you mean here. A semaphore has a counter. You can signal for one run and only one if you want. 3)Not sure what this means, I suppose I gotta' read up 4) Yeah, this is where semaphores get ugly. Thanks for taking your time. Appreciate it.

by seivan 14y ago

awj 14y ago

They are, but in a similar way to how objects are basically just structs in disguise. You can use semaphores to build promises, but like all other abstractions it's better to have it be shared amongst all the code you use. The "get the result of this computation or tell me when it ends and maybe tell me about progress" pattern is common enough that it might as well get written once and be a generally available tool.

seivan 14y ago
True. Going to look if I can build a generic way of doing promises via semaphores in obj-c so the code base follows the same pattern overall. Just for fun, I suppose there are already better solutions out there. But none of them use signals.

Strilanc 14y ago

The concepts are similar. However: - Promises don't block the caller. You don't wait, you provide a method to call on completion. - 'Signaling' a promise (completing it) causes all callbacks to run, instead of just one. - Promises never transition from completed to not-completed. They settle. - Promises naturally propagate values. Semaphores can be useful for implementing a promise, but they're not quite the same.

seivan 14y ago
1) Yeah I guess that's what semaphores are for, but the way to mitigate that is to block in a different queue. :-) Not saying this is the right way, I am saying this is part of me refactoring deep nested blocks. It's the middle ground before doing it properly. 2) Not sure what you mean here. A semaphore has a counter. You can signal for one run and only one if you want. 3)Not sure what this means, I suppose I gotta' read up 4) Yeah, this is where semaphores get ugly. Thanks for taking your time. Appreciate it.