[PATCH 1/8] [v2] wsdapi: Add wsdapi_internal.h for shared internal function and macro definitions.

[Owen Rudge]

Version 2: Incorporates improvements suggested by Huw; split patches up 
further.

Signed-off-by: Owen Rudge <orudge(a)codeweavers.com>
---
  dlls/wsdapi/address.c         |  6 +-----
  dlls/wsdapi/wsdapi_internal.h | 35 +++++++++++++++++++++++++++++++++++
  dlls/wsdapi/xml.c             |  7 +------
  3 files changed, 37 insertions(+), 11 deletions(-)
  create mode 100644 dlls/wsdapi/wsdapi_internal.h

[Huw Davies]

On Thu, Mar 15, 2018 at 09:44:28PM +0000, Owen Rudge wrote:
> Version 2: Incorporates improvements suggested by Huw; split patches up
> further.

Hi Owen,

I think the patch ordering is now much better.  I've added a few
comments on specific patches.

Have you thought about thread safety at all?  Is the api supposed to
be thread safe?

Huw.

[Owen Rudge]

Hi Huw,
> I think the patch ordering is now much better.  I've added a few
> comments on specific patches.

Thanks again, I'll take note of these.
> Have you thought about thread safety at all?  Is the api supposed to
> be thread safe?

I can't see anything on MSDN indicating thread safety for this API. For the Publisher interface at least, it's generally a case that you'll set up the publisher, register a notification callback interface, and call Publish, which one would assume you'd do on a single thread. The callbacks from WSD will almost always be executed on a different thread (so the client will need to ensure thread safety there), and the client may then call other Publisher functions (e.g., MatchProbe).

Internally the publisher listening threads, which will execute the callback functions (patches still to be submitted) are thread-safe.

Thanks,

Owen