search

nemequ / sqlheavy

Automatically exported from code.google.com/p/sqlheavy
Other
5 stars 4 forks source link

Recycle threads #11

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago 
The async methods rely on launching a background thread to do the blocking 
work.  Today the implementation creates a new thread for each operation using 
Thread.create().  This isn't horrible, but GLib's ThreadPool class provides a 
nice mechanism for re-using threads, sharing them with other pools, and 
releasing/destroying them when they've not been used in a while.  It would be 
nice if ThreadPool was used instead.

Original issue reported on code.google.com by jim%yorb...@gtempaccount.com on 6 Jul 2011 at 11:18

GoogleCodeExporter commented 9 years ago 
I disagree—using Thread.create is horrible… I don't know what I was 
thinking.

I'm planning a significant rewrite of the async code right now and this bug 
will be obsolete when that happens. I'm not yet sure whether I will use 
GThreadPool, but I will be recycling threads.

If you need this fixed urgently let me know, otherwise I'm just going to leave 
it as-is until the rewrite (probably a couple of weeks).

Original comment by nem...@gmail.com on 10 Jul 2011 at 12:42

GoogleCodeExporter commented 9 years ago 
No urgency, but since our app is async-heavy, we'd certainly like to see such a 
change.

Re: the async rewrite, will this involve an API change or merely internal 
refactoring?

Original comment by jim%yorb...@gtempaccount.com on 12 Jul 2011 at 7:06

GoogleCodeExporter commented 9 years ago 
Mostly internal refactoring. There may be some additions, but I don't think 
there will be any API/ABI breaks.

Of course, if you have any problems with the current API now would be a very 
good time to let me know.

Original comment by nem...@gmail.com on 13 Jul 2011 at 4:00