It is reproducible by testing tests/openpgp/multisig.scm with keyboxd enabled (it hangs), with the modification of following.

diff --git a/g10/call-keyboxd.c b/g10/call-keyboxd.c
index 7f4d5f493..e4bf22159 100644
--- a/g10/call-keyboxd.c
+++ b/g10/call-keyboxd.c
@@ -223,7 +223,7 @@ open_context (ctrl_t ctrl, keyboxd_local_t *r_kbl)
           return err;
         }
 
-      err = kbx_client_data_new (&kbl->kcd, kbl->ctx, 1);
+      err = kbx_client_data_new (&kbl->kcd, kbl->ctx, 0);
       if (err)
         {
           assuan_release (kbl->ctx);

The problem of hang of tests/openpgp/multisig.scm is solved by rGef4f22b9d98b: gpg: Graceful exit for signature checking with --batch.
But the problem itself is not yet solved.

It looks like having the datastream_thread may be not worth.
One possibility is to implement synchronous read from pipe in kbx_client_data_wait, instead of datastream_thread.

Test with Wine (i686) emulation, I encountered another hang at: Checking armored_key_8192

A change of pipe buffer size fixed the hang.

diff --git a/common/exechelp-w32.c b/common/exechelp-w32.c
index f63341e7c..2307ec59a 100644
--- a/common/exechelp-w32.c
+++ b/common/exechelp-w32.c
@@ -271,7 +271,7 @@ create_inheritable_pipe (HANDLE filedes[2], int flags)
   sec_attr.nLength = sizeof sec_attr;
   sec_attr.bInheritHandle = TRUE;
 
-  if (!CreatePipe (&r, &w, &sec_attr, 0))
+  if (!CreatePipe (&r, &w, &sec_attr, 4096*4))
     return -1;
 
   if ((flags & INHERIT_READ) == 0)

tests/openpgp/import.scm hangs with 4096*4.

I now use 4096*8. All tests go well.

Calling assuan_release before kbx_client_data_release is the best (and we join the thread).

I considered (and tested, actually) use of select before the call of es_read to avoid blocking holding estream lock.
This works for POSIX. For Windows, it seems no easy way for a pipe to block with something like select.