Remove duplicate worker instantiation

[Matheos96]

It seems like the worker instantiated and saved to the variable "worker" is the one used to create the service, however, it is not the one added to the local list of workers. An unused NEW worker instance is instead added to the list. Effectively, each loop we create two worker instances, one in vain.

[Tewr]

Thank you, much appreciated. Hope not too many people copy pasted this error, it's been there for years,,😬

[Matheos96]

Glad to get a contribution in :smiley: Might well be my first ever contribution to an open source project tbh.

BTW, it also came to mind that what is the purpose of the workers and backgroundServices caches in this example page? I was hoping to see an example of them used for IDisposable implementation or something, but it is unclear to me what their purpose are in the code's current state? I see that they both implement the new IDisposableAsync, so perhaps that was the intenion? I remember reading though that u should probably implement both IDispoable and IDisposableAsync together at all times to support syncronous disposing too :)

[Tewr]

what is the purpose of the workers and backgroundServices caches in this example page

This is an example of pooling, although I admit that it's not a very useful pooling strategy example. No real strategy here at all for maintaining or calculating a pool size. Though is a good start for a general pooling setup, and also a manual test just to show that multiple concurrent workers can solve a problem together, possibly faster than a single worker.

Example scenario for this page: You can run the example with 10 workers. And then run it again with 5 workers, but this time avoiding the startup cost, as you already have 10 workers in the pool, 5 can be re-used. The page lets you set the amount of workers, but I guess the general idea would be to determine it somehow from current workload.

For many cpu intensive scenarios, where we talk about several seconds or worse of processing, I'd say maintaining a pool of X workers would be interesting.

If you're only looking to save your ui thread from being frozen for a few milliseconds, pooling is probably not worth it.

[Tewr]

Regarding disposable, this api was initially fully asynchronous due to the way jsinterop was implemented in earlier blazor versions. Today, synchronous dispose could probably be implemented but I'd say for an api with a general purpose of executing long-running tasks without freezing the main thread it's probably a bad idea to encourage synchronous programming. On the flip side, the mozilla documentation states the worker would be killed off immediately without any chance to finish current work, so why not. Might work just fine without any freezeup whatsoever.

[Matheos96]

Example scenario for this page: You can run the example with 10 workers. And then run it again with 5 workers, but this time avoiding the startup cost, as you already have 10 workers in the pool, 5 can be re-used.

Ah of course! Completely overlooked the influence it has when the button is clicked multiple times. That does make sense :+1:

Regarding disposable, this api was initially fully asynchronous due to the way jsinterop was implemented in earlier blazor versions.

Makes sense, and yea I agree about the encouragement of synchronous programming.. I was just refering to the practises suggested by Microsoft but I guess it may not be super important for us who are mainly dealing with "modern" .NET interfaces which support IAsyncDisposable. In the context of older interfaces and .NET code I guess it would be more crucial to support both :)

BTW, it looks like we are looking to make use of this library in our Blazor Wasm app in the near future :) We discussed it today and I got the thumbs up as we need to improve our applications calculations and "loading" times by A LOT and we have quite a lot of work which could be done in parallel. We are currently on .NET 6 but are looking to upgrade to .NET 8 in the coming months, hopefully the NuGet will get a stable release for .NET 8 in the mean time :D We were hoping to see native multi-threading in .NET 8 but that looks quite far of as of now but hopefully BlazorWorker will serve us well until that day comes!