phobos / tango / ares
foo at bar.com
Sat Feb 10 21:12:37 PST 2007
Charles D Hixson wrote:
> kris wrote:
>> Charles D Hixson wrote:
>>> I'm not sure whether you were quoting the documentation, or reporting
>>> your understanding. If you were quoting the documentation, I think
>>> it needs editing.
>> From the doc: "Please note that the class itself is stateful, and
>> therefore a single instance is not shareable across multiple threads."
>> Thus, it is considered unwise to share a single instance of Sprint
>> across multiple threads. However, multiple threads /can/ share a
>> single instance if they follow this pattern:
>> synchronized (GlobalSprint)
>> GlobalSprint ("do my formatting", with, these, args);
>> This is a fairly standard mechanism in D for sharing resources across
>> threads, and it's what I had referred to.
>> But there's no reason to do this kind of thing at all. The use-case
>> for Sprint is to keep a handy formatter around for doing fast and
>> convenient layout. Adding synchronized to the mix tends to defeat one
>> of those desirable attributes, so we don't recommend it :)
>> If you're content to stash layout content into a temporary buffer
>> instead, there's Formatter.sprint() which takes an output array. The
>> output array in such a case would typically be stack-based.
> The problem that I ran into with this before didn't involve multiple
> threads...but it did involve writing out to a file and to a console.
> Unfortunately, It's been several months, so I don't remember the
> particulars. The resolution, however, was to allocate multiple buffers
> within the same routine. It might have involved buffering several
> different items within the same statement. I think that may have been
> where things went wrong. And my choices were to allocate several
> different buffers, or to break the statement into several different
> That sounds right, but don't depend on it. As I said it's been several
If you /retained/ a reference to the internal content, and then
subsequently wrote over it via a second usage, then yes. You just
witnessed a mutated alias at work. That's to be expected from any
mutable shared state (multi-threaded or otherwise), unless you
explicitly .dup the results before you stash them away (which then
eliminates the alias).
Still, if this little wrapper is causing such difficulties, perhaps it
should be removed instead. Embedding the .dup in the return value is
certainly one alternative, but then that would defeat the overall intent
More information about the Digitalmars-d-learn