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().
See conversation I had with Julliard below.
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.
Mike
<mike_m> julliard: i have a dilemma implementing SignalObjectAndWait <mike_m> the object to signal can be a semaphore, event flag, etc <mike_m> i get a handle <mike_m> so i have to resolve the object type by dereferencing the handle <mike_m> however, different objects require different permissions <mike_m> so a semaphore requires SEMAPHORE_MODIFY_STATE but a mutex does not <mike_m> so in the object->signal method, i'm going to pass an obj_handle_t instead of a struct object <mike_m> which is a little bit inconsistent <mike_m> is this still consistent with implementing an obj->ops->signal() ? <mike_m> esp. if it is obj->ops->signal( obj_handle_t ) ? <mike_m> or should i extract the handle's permissions and pass that to signal( struct object *obj, DWORD perms ) ? <mike_m> (you were right that this function is strangely designed) <julliard> mike_m: passing a handle to an object function is not good <mike_m> yeah. <julliard> i guess you'll need to do it by hand <mike_m> you mean without the function pointer <mike_m> without an obj->ops->signal function <julliard> yes