Interesting issue. I can see the need to make this configurable
though. In some cases it would be nice to make sure that these
background tasks do not run concurrently as concurrency issues can
result.
For example, I might have a URL fetch tied to a user interface
button. When the URL returns, I update an internal model with new
data. If the fetch is slow to load, the user will keep mashing the
button, resulting in multiple requests. It would be nice to have
those requests single threaded, rather than having to worry about 5
requests returning asychronously, and having to synchronize my model
update code.
Also, as it appears that the default is currently single threading, a
change to make the pool larger could break any apps that depend on the
single threading behavior.
On Jun 26, 12:24 pm, Romain Guy <romain...@google.com> wrote:
> Hi,
>
> It's a bug and your workaround is correct. I'll fix this right away.
>
>
>
>
>
> On Fri, Jun 26, 2009 at 9:27 AM, Jayesh Salvi<jayeshsa...@gmail.com> wrote:
> > Hi,
>
> > I am replacing the multithreaded code in my app with the AsyncTask from 1.5.
> > I found that two AsyncTasks do not work concurrently. I investigated a bit
> > and found a workaround; I would like second opinion if my solution is right.
> > OR if there is a better solution.
>
> > AsyncTask allows the app to do a task on a thread other than the UI thread.
> > But IIUC, it only provides a single thread on which a queue of tasks is
> > performed. Therefore, if one of the task is to wait on some event (n/w or
> > sleep) then all other tasks will wait for it to finish.
>
> > To elaborate with the coding example:
> > <code>
>
> > public class MyTask extends AsyncTask<...>
> > { ... }
>
> > // On the UI thread execute two tasks
> > MyTask mt1 = new MyTask().execute(args);
>
> > MyTask mt2 = new MyTask().execute(args);
>
> > </code>
>
> > In the above code both the execute calls will return immediately and free up
> > the UI thread; however mt1 will be executed first and mt2 will have to wait
> > until mt1 finishes.
>
> > Thanks to the android's open source, we can see implementation of AsyncTask.
> >http://google.com/codesearch/p?hl=en&sa=N&cd=2&ct=rc#uX1GffpyOZk/core...
>
> > I copied AsyncTask.java as UserTask.java in my project and changed the value
> > of CORE_POOL_SIZE to 5. This makes the thread pool to use 5 threads to
> > multiplex the queued AsyncTasks. This indeed solved my problem. Now if mt1
> > blocks on a sleep; mt2 goes ahead and finishes its job.
>
> > Here are some questions for those who know more about AsyncTask
> > implementation:
>
> > Is this work-around right?
> > If yes, can the CORE_POOL_SIZE be made configurable in future, via an API
> > call?
> > Is there a solution by which multiple thread pools can be used?
>
> > Let me add that, I am aware that this is a phone and not a web server - I am
> > not using 10s of threads to do network I/O. However a single thread is not
> > sufficient for my app either.
>
> > Please let me know. Thanks in advance.
>
> > Jayesh
>
> --
> Romain Guy
> Android framework engineer
> romain...@android.com
>
> Note: please don't send private questions to me, as I don't have time
> to provide private support. All such questions should be posted on
> public forums, where I and others can see and answer them
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers-unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
-~----------~----~----~----~------~----~------~--~---
