Admittedly, I am much more familiar with the threadpool in .NET than I am in Mono, so if I say something that is full of **** (aka bad stuff), please chime in.
I'm pulling this from memory back in .net 2 days, so it could be complete whack. If you queue up a bunch of threadpool threads in .NET, they don't always run at the same exact moment. The TP uses some kind of internal monitors to queue the threads up and run them as "resources permit." I found this out when I had an application that was making async http calls and it never would go beyond a few tp threads running in parallel when I had a small amount of bandwidth. When I had a large amount of bandwidth, it would exhaust the tp. Another issue I ran into was the relationship between the tp and the http requests. iirc, even in .net 2 sync requests, a tp thread was used, which meant that one tp call used two tps (the call itself and one for a sync tp call). I'm sure that this has improved with .net 4 as I am currently queuing up tons of tasks and executing them one right after the other. My suggestion in this would be to run it, see what the results are over a bad connection, and then try to improve things. A queue of 1 at a time and a tp to handle this off the ui thread sounds like the right way to start. I am guessing that if the tp algorithm in MT is like the one in .NET, the bandwidth will severely limit what you can do. Also, I'd look at using the task parallel library(tpl). if I have read what is trying to be accomplished correctly, I think that it will give you most of what you want. I know that in the .NET world, there is a move away from the TP and a move towards TPL and such. Though, I admit that I don't know the specifics of what is happening under the covers and would greatly appreciate to get more better info that what I have (which isn't much). Admittedly, debugging is going to be problematic, but its hard to debug threads anywhere. Wally > Date: Thu, 23 Feb 2012 12:06:52 +1300 > From: [email protected] > To: [email protected] > Subject: Re: [MonoTouch] Threading best practice > > > >>>>>> > -Have a queue with the 100 requests. > -Start a background thread with that keeps an eye on how many requests > are in progress > -Inside the thread start the async requests one by one untill you have > reached your limit. > -When each of the requests call back update the status of how many > requests are in progress. > -End the whole thing when you are done processing. > <<<<<< > > instead of having a separate thread to monitor the queue, you could just have > a method (WebCallDone say) that is called when each async web call returns. > WebCallDone check the queue and a count of current pending calls and fires > another call off the queue if required. Queue operations and count checking > need to be thread safe obviously. > > _______________________________________________ > MonoTouch mailing list > [email protected] > http://lists.ximian.com/mailman/listinfo/monotouch
_______________________________________________ MonoTouch mailing list [email protected] http://lists.ximian.com/mailman/listinfo/monotouch
