On Wed, Oct 27, 2010 at 05:38:24PM +0100, Andy Pugh wrote: > On 27 October 2010 17:09, Jeff Epler <jep...@unpythonic.net> wrote: > > > It's a dirty trick and I'd rather see it get as little use as possible.. > > Is there an easy, elegant way to make it less dirty? I can see many > uses for it (encoders going automatically into counter-mode, bldc > drivers knowing whether to use encoder or hall-sensor feedback spring > to mind)
You're right. Either I shouldn't use the trick here, or other components should feel free to use the trick. Which do we want to do? First, let me summarise what the trick *is*. After hal_pin_new returns, the pin points at the internal "dummysig". The dummysig exists so that it's always permitted to dereference a pin, regardless of whether a pin is connected. When a pin is connected to any signal, the address it points to is some other address than the dummysig. If the dummysig address is stored just after hal_pin_new, this enables: * test in constant time and from a RT thread whether the pin is connected to any signal * generate a value internally onto the dummysig that is later read as the pin's value when the pin is not connected to any signal There are some reasons to *not* use this trick in hal components: * In the future we might see a way to change the design in a way that makes the trick unusable (for instance, something that doesn't require the dummysig at all) * The hal lock is held during the time between hal_pin_new and the copy of the dummysig address. Instead, the assumption that makes this safe is that the only possible pin-linker is the same halcmd that is waiting for this component to be ready. We might want to violate this assumption sometime in the future (and you can probably violate it now just by running two halcmds at the same time) * The trick depends on whether a signal is connected, not whether a signal with a writer is connected. So for instance, connecting a signal and then scoping the signal will modify the component's behavior. (thanks to SWP for identifying this problem) What other considerations (uses or problems) are there than the ones I've identified? Shall we decide to use this trick freely, or to use it not at all? If we decide to use it freely, should we create some kind of API to make its use more explicit? Jeff ------------------------------------------------------------------------------ Nokia and AT&T present the 2010 Calling All Innovators-North America contest Create new apps & games for the Nokia N8 for consumers in U.S. and Canada $10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store http://p.sf.net/sfu/nokia-dev2dev _______________________________________________ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
