[PATCH 6/6] msvcp140_atomic_wait: Implement __std_bulk_submit_threadpool_work.

[Piotr Caban]

Hi Daniel,

On 1/26/22 23:50, Daniel Lehman wrote:
> - /* canceling bulk submit */
> - workcalled = 0;
> - work = p___std_create_threadpool_work(threadpool_workcallback, &workcalled, NULL);
> - ok(!!work, "failed to create threadpool_work\n");
> - p___std_bulk_submit_threadpool_work(work, 1234);
> - p___std_wait_for_threadpool_work_callbacks(work, TRUE);
> - p___std_close_threadpool_work(work);
> - ok(workcalled < 1234, "expected some work to be canceled, got %d\n", workcalled);

The workcalled < 1234 occasionally fails on my machine (and if it 
doesn't we end with workcalled around 1230). Please remove the test or 
find a way to avoid the race.

Please also use InterlockedIncrement when updating workcalled from 
multiple threads.

Thanks,
Piotr

[Daniel Lehman]

> The workcalled < 1234 occasionally fails on my machine (and if it doesn't we end with workcalled around 1230). Please remove the test or find a way to avoid the race.

I wanted a way to show the 2nd argument was really a cancel, but wasn't sure about the best way.  the 1234 seemed to work consistently for my box - would a higher number be ok?   if not, would removing the test for now be ok, to avoid random failures?
> Please also use InterlockedIncrement when updating workcalled from multiple threads.

Ah, right.  will do

Thanks
daniel

[Piotr Caban]

On 1/27/22 16:04, Daniel Lehman wrote:
> > The workcalled < 1234 occasionally fails on my machine (and if it doesn't we end with workcalled around 1230). Please remove the test or find a way to avoid the race.
>
> I wanted a way to show the 2nd argument was really a cancel, but wasn't sure about the best way.  the 1234 seemed to work consistently for my box - would a higher number be ok?   if not, would removing the test for now be ok, to avoid random failures?

I don't really like increasing the number - it seems fragile and the 
number is already quite big. I think it's better to remove the test. You 
can also add Sleep in callback but it's not the nicest solution either.