You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I came into a problem with the implementation of some of this library's so called "async" methods, declared on DynamicEnumerableAsyncExtensions.cs , like "ToDynamicListAsync", so I decided to create an account just to talk about it.
The thing is I was really expecting these methods to be truly asynchronous. Of course, before using them I did not know the details of their implementation (and I think no one should care about them as we assume they are susceptible to change over time).
Usually I only worry about documentation and method names unless I suspect the method's declaration/documentation is lying (as I think it is the case).
I find it very dangerous for third-party libraries to create new threads from the pool, specially when they just do it without any real need, just to achieve a fake asynchronous implementation, which does not add any real feature to the library.
What is the point of providing methods like these? When a library offers asynchronous methods what I expect from them is a truly asynchronous implementation with real benefits.
By creating new threads without alerting the users of the library, it can lead to unwanted results and it is not the best use of system resources, which can probably have a negative impact on performance. The threadpool is an app-global resource, so you should leave the callers of your library to decide how and when they want to use it.
Using these methods in certain scenarios gave me some problems, cause their implementations are not truly asynchronous and I was not expecting them to create new threads under the hood. Threads I do not have control over.
As I said before, I do not think the library benefits from these methods and they are very likely to cause unwanted and unnecessary problems, so I would encourage you to remove them, as anybody can just implement this asynchronous versions on their own, with a more appropriate and manageable usage of resources depending on their needs.
PS: What was the motivation for creating these methods and why was this implementation chosen? Investigating a little bit, I found this old request: Async support for ToDynamicList() #96 , but it made no sense. As it was stated on that post, the asynchronous implementation would not provide any real benefit, and even so, it was included in the library, introducing the aforementioned potential problems it may lead to and no real benefit for developers.
Thank you in advance for reading and maybe considering this humble request!
Regards.
The text was updated successfully, but these errors were encountered:
Hello there:
I came into a problem with the implementation of some of this library's so called "async" methods, declared on DynamicEnumerableAsyncExtensions.cs , like "ToDynamicListAsync", so I decided to create an account just to talk about it.
The thing is I was really expecting these methods to be truly asynchronous. Of course, before using them I did not know the details of their implementation (and I think no one should care about them as we assume they are susceptible to change over time).
Usually I only worry about documentation and method names unless I suspect the method's declaration/documentation is lying (as I think it is the case).
I find it very dangerous for third-party libraries to create new threads from the pool, specially when they just do it without any real need, just to achieve a fake asynchronous implementation, which does not add any real feature to the library.
What is the point of providing methods like these? When a library offers asynchronous methods what I expect from them is a truly asynchronous implementation with real benefits.
By creating new threads without alerting the users of the library, it can lead to unwanted results and it is not the best use of system resources, which can probably have a negative impact on performance. The threadpool is an app-global resource, so you should leave the callers of your library to decide how and when they want to use it.
Using these methods in certain scenarios gave me some problems, cause their implementations are not truly asynchronous and I was not expecting them to create new threads under the hood. Threads I do not have control over.
As I said before, I do not think the library benefits from these methods and they are very likely to cause unwanted and unnecessary problems, so I would encourage you to remove them, as anybody can just implement this asynchronous versions on their own, with a more appropriate and manageable usage of resources depending on their needs.
PS: What was the motivation for creating these methods and why was this implementation chosen? Investigating a little bit, I found this old request: Async support for ToDynamicList() #96 , but it made no sense. As it was stated on that post, the asynchronous implementation would not provide any real benefit, and even so, it was included in the library, introducing the aforementioned potential problems it may lead to and no real benefit for developers.
Thank you in advance for reading and maybe considering this humble request!
Regards.
The text was updated successfully, but these errors were encountered: