Hi,
While running your changed tests on Windows, I think I found new failures.
Being a bot and all I'm not very good at pattern recognition, so I might be
wrong, but could you please double-check?
Full results can be found at
http://testbot.winehq.org/JobDetails.pl?Key=25553
Your paranoid android
On Mon, May 13, 2013 at 3:45 AM, Hans Leidekker wrote:
> ...
>
> I don't see why you're still using these defines. It's unlikely that this code
> will work if NETLINK_ROUTE is defined but RTMGRP_IPV4_IFADDR isn't, for
> example.
>
> If there are versions of the netlink headers that don't have all
On Fri, 2013-05-10 at 20:07 -0600, Erich E. Hoover wrote:
> +/***
> + * IPHLPAPI_createmonitorhandle (INTERNAL)
> + *
> + * Routine to create the interface monitoring handle for NotifyAddrChange
> requests.
> + */
>
On Fri, May 10, 2013 at 8:27 AM, Hans Leidekker wrote:
> ...
> I think it would be nicer to push the platform specifics to helper functions
> (e.g. setting up the socket or checking for an address change) and use the
> usual
> header defines (HAVE_LINUX_NETLINK_H and/or HAVE_SYS_KERN_EVENT_H) for
On Fri, 2013-05-10 at 08:00 -0600, Erich E. Hoover wrote:
> On Fri, May 10, 2013 at 3:48 AM, Hans Leidekker wrote:
> >
> > On Wed, 2013-05-08 at 15:34 -0600, Erich E. Hoover wrote:
> > > ...
> > > +#ifdef NLMSG_OK
> > > +# define WINE_LINKMON_FAMILY PF_NETLINK
> > > +# define WINE_LINKMON_
On Fri, May 10, 2013 at 3:48 AM, Hans Leidekker wrote:
>
> On Wed, 2013-05-08 at 15:34 -0600, Erich E. Hoover wrote:
> > ...
> > +#ifdef NLMSG_OK
> > +# define WINE_LINKMON_FAMILY PF_NETLINK
> > +# define WINE_LINKMON_TYPE SOCK_RAW
> > +# define WINE_LINKMON_PROTO NETLIN
On Wed, 2013-05-08 at 15:34 -0600, Erich E. Hoover wrote:
> +#ifdef HAVE_LINUX_NETLINK_H
> +# include
> +#endif
> +#ifdef HAVE_LINUX_RTNETLINK_H
> +# include
> +#endif
> +
> +#ifdef NLMSG_OK
> +# define WINE_LINKMON_FAMILY PF_NETLINK
> +# define WINE_LINKMON_TYPE SOCK_RAW
> +# d
On Tue, May 7, 2013 at 12:26 PM, Hans Leidekker wrote:
> ...
> It's a system-wide event so the server seems to be a pretty good candidate
> to handle it, and it wouldn't need any extra threads.
> ...
Ok, how about something like the attached? (I assume the first patch is OK)
Best,
Erich
0002-
On Tue, 2013-05-07 at 10:04 -0600, Erich E. Hoover wrote:
> On Tue, May 7, 2013 at 3:14 AM, Hans Leidekker wrote:
> > ...
> > TerminateThread is not the right tool here. If the thread is blocked on the
> > recv call while being terminated it will leak the netlink socket.
> >
> > You'd need a way t
On Tue, May 7, 2013 at 3:14 AM, Hans Leidekker wrote:
> ...
> TerminateThread is not the right tool here. If the thread is blocked on the
> recv call while being terminated it will leak the netlink socket.
>
> You'd need a way to synchronize the threads, but an overhead of one thread per
> caller
On Mon, 2013-05-06 at 19:23 -0600, Erich E. Hoover wrote:
> --- a/dlls/iphlpapi/iphlpapi_main.c
> +++ b/dlls/iphlpapi/iphlpapi_main.c
> @@ -210,8 +210,14 @@ DWORD WINAPI
> AllocateAndGetIpAddrTableFromStack(PMIB_IPADDRTABLE *ppIpAddrTable,
> */
> BOOL WINAPI CancelIPChangeNotify(LPOVERLAPPED ov
11 matches
Mail list logo
