Since the goal is to generate the salt for PBKDF2, there is no need for an efficient (as in fast) random generator: PBKDF2 is (purposely) compute-intensive. Further, in many uses of PBKDF2 (e.g. storing a password), the salt is generated once, stored, and reused many times, further lowering the concern over efficiency of the salt generation. As the saying goes: premature optimization is the root of all evil.
In this usage, you also do not need a precisely uniform distribution (as would be the case for a random generator used e.g. in a casino machine). The (extremely slight) bias of RC4 is not a concern in the context of salt generation.
In that context, by far the most important criteria is that the generator should have low odds of generating twice the same value. As shown by recent anecdote in the context of RSA key generation (also here updated), that's difficult to implement correctly, especially on network appliances. The essential problem is that different runs of any deterministic RNG (such as RC4 or ISAAC) will generate the same result if fed the same input. Thus what matters is the seed material of the generator, and if/how its state is preserved across runs.
Two simple implementations of a generator that does not repeat are
Increment a persistent integer (stored e.g. in a data base), then output it. The integer should be wide enough to never overflow, or the number of runs limited.
Obtain the UTC time to some granularity, wait at least as long as that granularity, plus twice the maximum absolute value of the uncertainty of the source of time, plus one second (to account for leap second), then output the result.
Notice that both methods assume a single instance runs, and can be broken if the attacker can influence the system (reset the persistent integer, alter the clock setting...). And of course, these generators are predictable, not random generators. But assuming the availability of a single secret randomly-seeded Key, this is easy to fix: given the output N of a generator that does not repeat, output HMAC(Key,N).
Practical designs of good software RNGs combine seed material gathered using several techniques, including the above, CPU clock since boot, process time, RAM content at boot, hard disk and network latency, mouse position, keyboard presses and their timing, hardware serial numbers such as in hard disk and network cards...
For more in-depth discussion on the desirable properties and design of software RNGs, see yarrow. For physical design and testing, see e.g. Design of Testable Random Bit Generators.