To illustrate the latter point, let's revisit the function signature for the select() function:

int select (int width,               // Maximum handle plus 1
            fd_set *read_fds,        // Set of "read" handles
            fd_set *write_fds,       // Set of "write" handles
            fd_set *except_fds,      // Set of "exception" handles
            struct timeval *timeout);// Time to wait for events

The three fd_set arguments specify the handles to use when selecting for each event type. The timeout argument is used to specify a time limit to wait for events to occur. The particular details concerning these parameters vary in only minor ways across platforms. Due to the changing nature of I/O handles (and, thus, fd_set) across platforms, however, the meaning of the first argument (width) varies widely across operating systems:

* On UNIX, I/O handles start at the value 0 and increase to an OS-defined maximum limit. The meaning of the width parameter on UNIX is therefore "how far into the fd_set to scan for handles"; that is, it's defined as the highest numbered handle in any of the three fd_set parameters, plus 1.

* On Win32, socket handles are implemented as pointers rather than as low-numbered integers. The width argument to select() is therefore ignored completely. Instead, each fd_set contains its own handle count.

* On other platforms, where handles may be integers that don't start at 0, the definition may differ yet again.

The size-related values in an fd_set are also computed differently depending on the characteristics of the platform's representation and its select() semantics. Any applications written directly to native OS APIs must therefore adapt to all these subtle differences, and each project may end up redesigning and reimplementing code that manages the proper value to supply for width. Addressing these portability differences in each application is tedious and error prone, which is why ACE provides the ACE_Handle_Set class.

AS> Еще раз — реализация в ACE некорректна, и точка. Реализовывать функциональность надо корректными средствами, а не абы как .

// Process.inl:
ACE_INLINE int
ACE_Process::terminate (void)
{
  if (this->getpid () != -1)
    return ACE::terminate_process (this->getpid ());
  else
    return -1;
}

int
ACE::terminate_process (pid_t pid)
{
#if defined (ACE_HAS_PHARLAP)
  ACE_UNUSED_ARG (pid);
  ACE_NOTSUP_RETURN (-1);
#elif defined (ACE_WIN32)
  // Create a handle for the given process id.
  ACE_HANDLE process_handle =
    ::OpenProcess (PROCESS_TERMINATE,
                   FALSE, // New handle is not inheritable.
                   pid);

  if (process_handle == ACE_INVALID_HANDLE
      || process_handle == 0)
    return -1;
  else
    {
      // Kill the process associated with process_handle.
      BOOL terminate_result =
        ::TerminateProcess (process_handle, 0);
      // Free up the kernel resources.
      ACE_OS::close (process_handle);
      return terminate_result ? 0 : -1;
    }
#else
  return ACE_OS::kill (pid, 9);
#endif /* ACE_HAS_PHARLAP */
}

AS>Ну, авторы нескольких других библиотек имеют на этот счет отдельное мнение

AS>>>Странно, что мне приходится это говорить именно вам, но эти файлы могут включаться неявно. Например, другим кроссплатформенным фреймворком. Хинт — попробуйте использовать ace и poco вместе

AS> Вы так и не поняли, о чем я. Проблемы будут — поскольку на этом завязана ACE.

Я не про то. Событие, созданное при помощи WSACreateEvent, ждут при помощи WFMO. Надо ли объяснять, что при наличии LSP, который подменяет эти функции на свои (т.е. хендл события будет не обычным евентом) вся эта конструкция отправляется в dev\null. Ждать надо при помощи WSAWaitForMultipleEvents и точка — а это, очевидно, отправляет всю реализаци WFMO реактора в топку.

E>>>>ACE::terminate_process (pid_t pid)
E>>>>

AS>Офигеть, дайте 2. Есть как минимум 2 функции с именем terminate. Это ACE_OS::terminate(pid) и ACE_Process::terminate(). Та, что метод — вообще без параметров, и имеет по идее в наличии хендл процесса, по-крайней мере, для вин32. В общем, я устал одно и то же говорить, право. Просто посмотрите исходники

Blocking and waiting for Completion Indication —
Applications may also choose to block while waiting for one
or more event objects to become set using
WSAWaitForMultipleEvents(). In Win16 implementations, this
will utilize a blocking hook as is currently provided for
standard blocking socket operations. In Win32
implementations, the process or thread will be truly
blocked. Since Winsock 2 event objects are implemented as
Win32 events, the native Win32 function
WaitForMultipleObjects() may also be used for this purpose.
This is especially useful if the thread needs to wait on
both socket and non-socket events.