On 01/06/2012 12:17 PM, Dmitry Torokhov wrote: > On Fri, Jan 06, 2012 at 12:09:36PM -0800, Chase Douglas wrote: >> I know there's a slight distinction between these two scenarios, but my >> point is that if you are doing multithreaded evdev reading from the same >> evdev fd, you are asking for trouble and you need to be careful. That >> even goes for modifying any of the other state through EVIOCSABS from >> multiple processes. And really, how many programs are out there reading >> from the same evdev fd in multiple threads. I'd wager a fair amount of >> money the answer is 0. > > I am really not concerned about what userspace might do - I've looked at > enough code to see all kinds of weird stuff. My task is to make sure > that kernel interface is sane and since it is userspace ABI matter I > want to be extra careful. Evdev by its very nature is thread unsafe. There's no way to atomically retrieve an event frame including all the new values up through the next EV_SYN. That's the meat and potatoes of evdev. If the base of an API is thread-unsafe, it does very little to add thread safety to functions surrounding it. If you want to make a line of demarcation to say that evdev reads are not thread-safe, but ioctls are, then that makes a slight bit of technical sense. However, it still seems like a fools errand to me, because no one will ever make a multithreaded program that opens an evdev device, accesses its ioctls through multiple threads, while never reading from the evdev fd. If for some reason someone actually does this, all they need is a simple mutex. I really think this is a waste of time when Henrik's patch is ready to go, is small and self contained, and meets everyone's needs. But this is the last I'll speak of it. -- Chase -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
