Naturally-asynchronous operations are not CPU bound and don't have a thread. For example, file reads are done in the I/O hardware which can be kicked off asynchronously without a thread, enabling concurrency. Whenever I come across resources that discuss this, they always use external-system-bound operations as examples, and they almost always have "like I/O or database operations".
ADO.NET has plenty of async methods, like SqlCommand.ExecuteReaderAsync, but one thing it doesn't have is System.Data.SqlClient.SqlDataAdapter.FillAsync.
Many resources covering this happily suggest that you just use Task.Run, like this one and this one, e.g.:
public Task<DataSet> GetDataSetAsync
(string sConnectionString, string sSQL, params SqlParameter[] parameters)
{
return Task.Run(() =>
{
using (var newConnection = new SqlConnection(sConnectionString))
using (var mySQLAdapter = new SqlDataAdapter(sSQL, newConnection))
{
mySQLAdapter.SelectCommand.CommandType = CommandType.Text;
if (parameters != null) mySQLAdapter.SelectCommand.Parameters.AddRange(parameters);
DataSet myDataSet = new DataSet();
mySQLAdapter.Fill(myDataSet);
return myDataSet;
}
});
}
But that code isn't truly asynchronous: there's still a thread.
So was it an intentional decision not to have FillAsync, and if so, why?
