[Soot-list] Singleton pattern in Soot

[Archie Cobbs]

Keith Lea wrote:
> I think the Singleton pattern used in Soot is a large hindrance to 
> developers who want to use Soot as a class library rather than as a 
> command-line tool. Soot's classes are generally not thread-safe, so the 
> singleton design prevents efficient implementations of many potential 
> uses of Soot (such as parsing code as an editor inspection in an IDE, 
> which is done with multiple threads by IDE's such as IntelliJ IDEA).
> 
> I would like to contribute a large change to Soot - modifying the 
> architecture to remove all dependency on singletons. However, it seems 
> that these changes might break a great deal of code which currently uses 
> Soot. I would attempt to preserve backwards compatibility wherever 
> possible, but I would not sacrifice good design for backwards 
> compatibility.
> 
> I wonder if I made these changes, if they would be accepted into the 
> Soot codebase. If not, I probably won't make the changes, as I don't 
> have the knowledge or time to maintain and update a separate branch of 
> the project.

There was a discussion about this (i.e., how to fix the singleton/single
thread prolem without breaking backward compatibility too badly) a while
back.. you might search the lists.

Basically, if you want the APIs to not change much, there must be some
implicit way to associate a Soot "singleton set" with the current thread.
E.g., a ThreadLocal would work -- maybe, depending on the application.
But that's really a workaround.

The other option is to change the API totally. E.g., you could pass
aruond an explicit "Scene" object. More stuff would become multithread
safe, etc.

Another possibility is for Scene (is that the right class? replace with
whatever the 'top level' class is .. maybe G?) to have no static methods.
Instead, you'd create a new Scene (or G or whatever) and then it would
have instance methods.. but each such object would require single-threaded
operation as before. The downside there of course is you don't get to
re-use cached state from previous runs.

So the bottom line here is, before you go create a patch you have to
answer the question, what's the best strategy?

-Archie

__________________________________________________________________________
Archie Cobbs      *        CTO, Awarix        *      http://www.awarix.com