Marton Balint (12020-01-24):
> I tested this on Windows7/10 and it does not seem to work. closesocket()
> indeed aborts the pending recv() call, but not shutdown(). CancelIoEx()
> seems to work though.
Using one of these to implement a pthread_cancel() that works for our
situation seems like the
On Thu, 23 Jan 2020, Matt Oliver wrote:
On Thu, 23 Jan 2020 at 08:12, Marton Balint wrote:
On Wed, 22 Jan 2020, Nicolas George wrote:
Marton Balint (12020-01-16):
It is not supported by every threading implementation, and the only
thing we
gain with it is an immediate shutdown of
On Wed, Jan 22, 2020 at 10:12 PM Marton Balint wrote:
>
>
>
> On Wed, 22 Jan 2020, Nicolas George wrote:
>
> > Marton Balint (12020-01-16):
> >> It is not supported by every threading implementation, and the only thing
> >> we
> >> gain with it is an immediate shutdown of receiving packets on
On Thu, 23 Jan 2020 at 08:12, Marton Balint wrote:
>
>
> On Wed, 22 Jan 2020, Nicolas George wrote:
>
> > Marton Balint (12020-01-16):
> >> It is not supported by every threading implementation, and the only
> thing we
> >> gain with it is an immediate shutdown of receiving packets on close and
On Wed, 22 Jan 2020, Nicolas George wrote:
Marton Balint (12020-01-16):
It is not supported by every threading implementation, and the only thing we
gain with it is an immediate shutdown of receiving packets on close and
avoiding the poll call before reading the data.
I don't think it is a
Marton Balint (12020-01-16):
> It is not supported by every threading implementation, and the only thing we
> gain with it is an immediate shutdown of receiving packets on close and
> avoiding the poll call before reading the data.
>
> I don't think it is a big issue if it takes 0.1 sec of delay
Am Di., 21. Jan. 2020 um 22:56 Uhr schrieb Marton Balint :
>
>
>
> On Fri, 17 Jan 2020, Michael Niedermayer wrote:
>
> > On Thu, Jan 16, 2020 at 01:20:16AM +0100, Marton Balint wrote:
> >> It is not supported by every threading implementation, and the only thing
> >> we
> >> gain with it is an
On Fri, 17 Jan 2020, Michael Niedermayer wrote:
On Thu, Jan 16, 2020 at 01:20:16AM +0100, Marton Balint wrote:
It is not supported by every threading implementation, and the only thing we
gain with it is an immediate shutdown of receiving packets on close and
avoiding the poll call before
On 1/17/2020 4:51 AM, Matt Oliver wrote:
> On Fri, 17 Jan 2020 at 18:44, Hendrik Leppkes wrote:
>
>> On Fri, Jan 17, 2020 at 12:30 AM Michael Niedermayer
>> wrote:
>>>
>>> On Thu, Jan 16, 2020 at 01:20:16AM +0100, Marton Balint wrote:
It is not supported by every threading implementation,
On Fri, 17 Jan 2020 at 18:44, Hendrik Leppkes wrote:
> On Fri, Jan 17, 2020 at 12:30 AM Michael Niedermayer
> wrote:
> >
> > On Thu, Jan 16, 2020 at 01:20:16AM +0100, Marton Balint wrote:
> > > It is not supported by every threading implementation, and the only
> thing we
> > > gain with it is
On Fri, Jan 17, 2020 at 12:30 AM Michael Niedermayer
wrote:
>
> On Thu, Jan 16, 2020 at 01:20:16AM +0100, Marton Balint wrote:
> > It is not supported by every threading implementation, and the only thing we
> > gain with it is an immediate shutdown of receiving packets on close and
> > avoiding
On Thu, Jan 16, 2020 at 01:20:16AM +0100, Marton Balint wrote:
> It is not supported by every threading implementation, and the only thing we
> gain with it is an immediate shutdown of receiving packets on close and
> avoiding the poll call before reading the data.
>
> I don't think it is a big
It is not supported by every threading implementation, and the only thing we
gain with it is an immediate shutdown of receiving packets on close and
avoiding the poll call before reading the data.
I don't think it is a big issue if it takes 0.1 sec of delay to close an udp
stream. Back when this
13 matches
Mail list logo
