Mike McCormack wrote:
I think this is a little ugly. I'd prefer to see this code do a switch on obj->ops and call the relevant function with the raw object instead of a handle.
I know it's ugly; I rewrote that bit three times, including once with an ops->signal() method. Implementing a object operation requires that the 3 operations are consistent. For example, the access flags required to perform must be consistent, so the get_handle_obj can be done only once. Unfortunately, semaphores and event flags require different permissions to execute ops->signal().
Ok, I see the problem now. The only alternative I can think of is to try to open the object with the GENERIC_WRITE access right and implement generic mappings for each object (these mappings are really needed anyway for other situaitons).
This seems to be pretty similar to select_on. Would it not be possible to use that function instead of duplicating that code?
I considered that. The problem is that we would have to signal the object in the middle of the setup for select_on(). That means passing new parameters to select_on(), and that function already looks a little busy.
You could refactor the function so that the wait_on bit is separate. That seems to be the only thing you have to do before signalling the object.
Rob