Decrement WorkCount

[Silber_Felix1 (Silber Felix)]

Looking at TWinThreadPool.QueueUserWorkItem
I think, if
Winapi.Windows.QueueUserWorkItem(WorkItemFunction, WorkItem, 0);

Returns false, TWinThreadPool.WaitWorkItems will wait till timeout because
FEvent.SetEvent will never be called, because FWorkCount will stay incremented.

function TWinThreadPool.QueueUserWorkItem(Proc: TNotifyEvent; Context: TObject): boolean;
var
  WorkItem: TWinWorkItem;
begin
  WorkItem := TWinWorkItem.Create(Proc, Context, Self);
  try
    InterlockedIncrement(FWorkCount);
    FEvent.ResetEvent;
    Result := Winapi.Windows.QueueUserWorkItem(WorkItemFunction, WorkItem, 0);
    if not Result then
     // maybe here you should InterlockedDecrement(FWorkCount) and if it's 0, FEvent.SetEvent;
      WorkItem.Free;
  except
    WorkItem.Free;
    raise;
  end;
end;

[wlandgraf (Wagner Landgraf)]

Is this causing real-world issues? In the end, it's a queued work item that is waiting to be finished, so a timeout is not a big deal.

The solution might be tricky as I think just decrementing FWorkCount is not enough, a FEvent set must be done if work items are set to zero, but then multi-threading must be taken into account, etc. Sparkle core code is rock solid and I'd be afraid of touching it for no good reason.

[Silber_Felix1 (Silber Felix)]

I came up with this, because we run into timeout on each shutdown.

First I thought it could be this case, but taking a closer look, I've found out that, our first xdata request starts another thread, that will never be finished.
So queued item never came to an end...

I just wanted to let you know, that this could be an issue.
I don't think this needs to be fixed right now.