On Tue, Sep 28, 2021, 07:22 ste...@eissing.org <ste...@eissing.org> wrote:
> > > Am 28.09.2021 um 14:10 schrieb ste...@eissing.org: > > > >> Am 28.09.2021 um 14:04 schrieb Yann Ylavic <ylavic....@gmail.com>: > >> > >> On Tue, Sep 28, 2021 at 1:08 PM ste...@eissing.org <ste...@eissing.org> > wrote: > >>> > >>> Does anyone know which platforms do *not* support WAKEABLE apr > pollsets? > >> > >> Last time I checked (IIRC) all platforms support it on the APR side, > >> every platform handles pipes at least it seems. > >> Possibly it wasn't the case some (long) time ago, we are probably > >> overly cautious with APR_POLLSET_WAKEABLE availability check in > >> mpm_event.. > >> > >>> > >>> And if http2 should support this, would be adding an own wakeup pipe > be the way to go? > >> > >> Looks overly cautious to me :) > > > > Uhm, due to an error report from Windows, I am reading the APR pollset > > implementation again. And Windows does not support polling on pipes? > > > > There is a special hack inside apr to realize a wakeup pipe, > > but otherwise it returns APR_EBADF. If I read it correctly... > > > > That would pose some major difficulties. > > Hmm, apr_file_pipe_create() under Windows makes me cry... > Indeed, what you think of as pipes are not what windows implemented, and while they have been stdio for years, the left a lot to be desired. This means I need another strategy under Windows. *sadge* > Such as true AF_UNIX pipes, introduced after the initial launch of Window 10/Server 2019. And can do one better in Server 2022/Windows 11 with actual edge triggered eventing. To bake this into apr, it needs to be run-time detected, at least if there continues to be a single binary for apr-1.dll, but our feature macros are all compile time. Compound this with the fact that MS supports named pipes, but isn't supporting socketpair to create a usefully unnamed pipe. None of this will work in the initial Windows 10/Server 2019 releases. At least this opens up a number of options that had been missing for 25 years.
