phobos / tango / ares

kris foo at
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.
> Mmmm...
> 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 
> statements.
> That sounds right, but don't depend on it.  As I said it's been several 
> months.

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 
also :)

- Kris

More information about the Digitalmars-d-learn mailing list