NTDLL: implement NtSignalAndWaitForSingleObject

[Mike McCormack]

> 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