Mike Patnode "mpatnode@..." wrote:
>> 1. There's almost no way to make me include code in the library that
>> will break current implementations.
> How do the poll and read interface break current implementations? In
> the changes I made, the old interfaces are still supported, just the
> mallocs are avoided.
Sorry for my ignorance. I didn't look close enough at the patch.
>> 2. If I ever introduce a new interface it will probably require to
>> install a callback function that would be called for each action
>> to be taken (eliminating the need for the current while loops,
>> that would be inside the library then).
> This has to do with the state machine in lirc_code2char? That sounds
> reasonable, but after looking more closely at the current
> implementation, as long as you pass in the context, you should still be
> thread-safe (though I haven't look closely). Also, due to the nature
> of the IR interface, threads shouldn't really be an issue.
> I wouldn't worry as much about the state machine as I would the memory
While you are right that memory management is not optimal it's definitely
not first priority. The TODO list currently is:
1. Solve problems due to every program maintaining its own state machine.
2. Add API for transmitting with lirc_client.
3. anything else
That's the reason why I'm very reluctant to make changes to the
lirc_client API before changes due to 1. and 2. are clear.