On Apr 17, 2013, at 21:58 , Ian Lance Taylor wrote:On Wed, Apr 17, 2013 at 9:13 PM, Godfrey van der Linden wrote:
I've implemented file tables to decode the AttrDeclFile field. Is there anybody around who knows this code? Also I've been looking at making the package thread safe, well the Type system anyway and new FileTable stuff anyway.
I more or less know the debug/dwarf code if you want to ask a
question. If you want to send in a code review, just use hg mail and
it will be sent to golang-dev.
Ian
I have a AttrDeclFile patch just about ready to go, and a couple of other small patches for concurrency support. Is it better to submit a couple of small patches with a narrow purpose or should I just submit a big patch with all of the work I have been doing to the package?
Also it seems to me that the (d *Data) Type cache is broken under concurrency. Using the go share communications not memory idea, I propose that to keep a typeCache in a Reader created for a CompileUnit. The Types are local to the compile unit in any case.
The API I propose is :-
// Type decodes the entry at offset within the dwarf.info section and returns a
// Type. It must be called in a single threaded context with respect to the
// dwarf.Reader object. Create a Reader for a CompileUnit and parallelise on
// each CompileUnit in an executable.
func (r *Reader) Type(off Offset) (Type, error)
The origin API is :-
// Type decodes the entry at offset within the dwarf.info section and returns a
// Type. It must be called in a single threaded context with respect to the
// underlying dwarf.Data object.
func (d *Data) Type(off Offset) (Type, error)
Am I on the right track?
Godfrey
--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
For more options, visit
https://groups.google.com/groups/opt_out.