Richard Braun, on Fri 02 Dec 2016 10:56:40 +0100, wrote:
> On Fri, Dec 02, 2016 at 10:43:04AM +0100, Samuel Thibault wrote:
> > Or simply
> >
> > (d[i].reply_port != MACH_PORT_NULL))
>
> Aren't there cases where an entry could remain uninitialized ?
Here, no, we have the same structure:
if
On Fri, Dec 02, 2016 at 10:43:04AM +0100, Samuel Thibault wrote:
> Or simply
>
> (d[i].reply_port != MACH_PORT_NULL))
Aren't there cases where an entry could remain uninitialized ?
--
Richard Braun
Richard Braun, on Fri 02 Dec 2016 10:28:48 +0100, wrote:
> > as well as in the error case of __io_select_request, and then just check
> > against MACH_PORT_NULL before destroy.
>
> So the condition would look like
>
> if (d[i].type && (d[i].reply_port != MACH_PORT_NULL))
Or simply
(d[i].reply
On Fri, Dec 02, 2016 at 08:41:21AM +0100, Samuel Thibault wrote:
> About the port leak in select discussed on IRC, I checked history a bit,
> this (000ef460744786571f51604e6de631b7168e239a):
>
> - if (d[i].type)
> + if (d[i].type & ~SELECT_ERROR)
> __mach_port_destroy (__mach_tas
Hello,
About the port leak in select discussed on IRC, I checked history a bit,
this (000ef460744786571f51604e6de631b7168e239a):
- if (d[i].type)
+ if (d[i].type & ~SELECT_ERROR)
__mach_port_destroy (__mach_task_self (), d[i].reply_port);
was added when handling EBADF , for whi
