On Tue, Jun 21, 2022 at 8:47 PM Mark Thomas wrote:
>
> On 21/06/2022 13:25, Rémy Maucherat wrote:
> > kOn Tue, Jun 21, 2022 at 12:41 PM Mark Thomas wrote:
> >>
> >> On 21/06/2022 08:53, Rémy Maucherat wrote:
> >>> On Tue, Jun 21, 2022 at 9:13 AM Mark Thomas wrote:
>
> Hi all,
>
>
On 21/06/2022 13:25, Rémy Maucherat wrote:
kOn Tue, Jun 21, 2022 at 12:41 PM Mark Thomas wrote:
On 21/06/2022 08:53, Rémy Maucherat wrote:
On Tue, Jun 21, 2022 at 9:13 AM Mark Thomas wrote:
Hi all,
See [1] for further background.
The current sendfile implementation for async HTTP/2 uses
kOn Tue, Jun 21, 2022 at 12:41 PM Mark Thomas wrote:
>
> On 21/06/2022 08:53, Rémy Maucherat wrote:
> > On Tue, Jun 21, 2022 at 9:13 AM Mark Thomas wrote:
> >>
> >> Hi all,
> >>
> >> See [1] for further background.
> >>
> >> The current sendfile implementation for async HTTP/2 uses a
> >> MappedB
On 21/06/2022 08:53, Rémy Maucherat wrote:
On Tue, Jun 21, 2022 at 9:13 AM Mark Thomas wrote:
Hi all,
See [1] for further background.
The current sendfile implementation for async HTTP/2 uses a
MappedByteBuffer as the source.
Unfortunately, MappedByteBuffer has some problematic side effects
On Tue, Jun 21, 2022 at 9:13 AM Mark Thomas wrote:
>
> Hi all,
>
> See [1] for further background.
>
> The current sendfile implementation for async HTTP/2 uses a
> MappedByteBuffer as the source.
>
> Unfortunately, MappedByteBuffer has some problematic side effects on
> Windows. The underlying fi
Hi all,
See [1] for further background.
The current sendfile implementation for async HTTP/2 uses a
MappedByteBuffer as the source.
Unfortunately, MappedByteBuffer has some problematic side effects on
Windows. The underlying file is locked until the MappedByteBuffer is
GC'd. This causes pro
