Jesper,
First off, thank you for the detailed answer, I very much appreciate you
taking the time to provide the background information. I had not
internalized how closely tied to the runtime the standard library is.
For this instance, I require extremely performant access to the underlying
Second and Nanosecond members of the time.Time structure which are not
exposed. I had been using an admittedly hackish wrapper that used the
unsafe package, but with the new monotonic functionality in 1.9 it changed
the layout and forced me to do it properly. Using calls to UnixTime() and
correcting the values was incurring more overhead than I would like (I did
benchmark it).
The alternate option is to package up the assembly calls in the runtime to
access the wallclock functions, but I may be right back in the same
position. Can I access the __vdso_ kernel provided functions in assembly
and have them be properly linked?
Optimally, I would like a direct access/set method for sec and nsec for the
time.Time structure, but that would require adding to the standard library.
Thank you,
Kris
On Sunday, October 15, 2017 at 5:51:04 AM UTC-6, Jesper Louis Andersen
wrote:
>
> The short answer: you can't, and it is a feature.
>
> The runtime "injects" certain functions into certain packages in order to
> build a bridge between the (internal) runtime and the "package world"
> accessible to programmers. Thus, they are only accessible in that package
> specific package (time).
>
> The reason for this choice is encapsulation. By not exposing a given
> function, the Go authors and developers are free to change the internal
> runtime interface, as long as they still provide the exported function
> Now(). If you were to get access to it, the Go 1.0 backwards compatibility
> guarantee would easily be broken for your program, since it is likely it
> will change in the future. Furthermore, any exposed function requires
> documentation. Some times you hide details from the outside world because
> the documentation effort is simply too large in the first place.
>
> The solution Go uses is fairly standard in language runtimes. You do not
> want to expose all of the runtime to the user. The reason is that this
> removes every notch of flexibility you have as a runtime developer, because
> most changes are going to break someones program in some way. As an aside,
> languages such as Ruby or Python are now very hard to optimize for, because
> they have exposed a vast set of internals to the outside world. This "locks
> them down" so to speak.
>
> If you do need more specific access, there is usually an underlying idea
> you have in mind. It would probably be better to discuss why you need the
> access in the first place. It might be useful to other people. The new use
> could be an extension to the current interface such that you still have the
> necessary compatiblity. It is, perhaps, also worth looking at for a Go 2.x.
>
> On Sun, Oct 15, 2017 at 2:59 AM traetox <tra...@gmail.com <javascript:>>
> wrote:
>
>> I would like to be able to call the runtime implemented "now()" function
>> similar to how the "time" package does.
>>
>> For example the Time.Now() function in the time package looks like the
>> following
>>
>> func now() (sec int64,nsec int32, mono int64)
>> func Now() Time{
>> sec, nsec, mono := now()
>> ...
>> }
>>
>>
>> When I build packages using "go build" using the same structure I get the
>> error:
>> missing function body for "now"
>>
>> How is this package built such that it can access the "now()" function
>> and how can I access those runtime implemented functions in my own packages?
>>
>> Thank you!
>>
>> --
>> 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...@googlegroups.com <javascript:>.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
--
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
