[9fans] nanosleep()?

[9fans] nanosleep()?

[Lucio De Re]

In porting the prof command from the Go distribution (src/cmd/prof),
absence of the nanosleep() function seems to be the final stumbling
block, at least for compilation purposes.  Any suggestions on how to
implement it?

++L

Re: [9fans] nanosleep()?

[ron minnich]

On Thu, Oct 27, 2011 at 9:07 PM, Lucio De Re <lucio@proxima.alt.za> wrote:
> In porting the prof command from the Go distribution (src/cmd/prof),
> absence of the nanosleep() function seems to be the final stumbling
> block, at least for compilation purposes.  Any suggestions on how to
> implement it?

well, it is unlikely to say the least that the OSes we have will let
you sleep for precisely one nanosecond. I'd be surprised if they even
hit a microsecond reliably ...

For a first pass, you could create a nanosleep for plan 9 that rounds
to milliseconds and then use sleep()

ron

Re: [9fans] nanosleep()?

[Anthony Martin]

ron minnich <rminnich@gmail.com> once said:
> For a first pass, you could create a nanosleep for plan 9
> that rounds to milliseconds and then use sleep()

Yup.  This is the right thing to do.  The prof command
in the Go distribution has a minimum sampling interval
of one millisecond so you don't even need nanosleep.

  Anthony

Re: [9fans] nanosleep()?

[Charles Forsyth]

>Implementing nanosleep() does not require enormous resolution,
>although there are complications.

well, yes. it requires that struct timespec crud as well.
the interaction with signals doesn't seem to be relevant.

at least it doesn't use ptrace directly!

Re: [9fans] nanosleep()?

[Charles Forsyth]

after looking at the source, i'd say nanosleep is the least of your troubles.

Re: [9fans] nanosleep()?

[Lucio De Re]

> after looking at the source, i'd say nanosleep is the least of your troubles.

You think that once it compiles, it will not work as required?  I have
not looked very deeply under the bonnet, so I must have missed
important details.

++L

Re: [9fans] nanosleep()?

[Charles Forsyth]

ppmaps might just work (depending on libmach, i suppose).
also, although it's supposed to profile at "regular" real-time intervals,
it seems to assume that regularity will just happen. perhaps it does.

Re: [9fans] nanosleep()?

[Lucio De Re]

> ppmaps might just work (depending on libmach, i suppose).
> also, although it's supposed to profile at "regular" real-time intervals,
> it seems to assume that regularity will just happen. perhaps it does.

I do wonder who assembled all these tools, I have found enough
mixtures of Plan 9 compatibilities and Posix-isms to cause me
indigestion.  But at this point I only want to eliminate compilation
errors in the Go build procedure under Plan 9, I don't really care if
some tools do not function as required, as long as they are not
essential to the build.

On the other hand, if the tools can be made to work correctly besides
compiling successfully, it will improve the likely acceptance of Go
and that ought to be a good thing.

++L

Re: [9fans] nanosleep()?

[Lucio De Re]

[-- Attachment #1: Type: text/plain, Size: 168 bytes --]

Oops, a heavy handed comment intended to amuse Charles rather than be
critical of the Go Authors.  I do not intend to offend anyone and I
apologise if I did.

++L

[-- Attachment #2: Type: message/rfc822, Size: 1776 bytes --]

From: Lucio De Re <lucio@proxima.alt.za>
To: charles.forsyth@gmail.com, lucio@proxima.alt.za, 9fans@9fans.net
Subject: Re: [9fans] nanosleep()?
Date: Fri, 28 Oct 2011 14:05:25 +0200
Message-ID: <755c0af9d04658f3d757fd5e5f29dd92@proxima.alt.za>

> ppmaps might just work (depending on libmach, i suppose).
> also, although it's supposed to profile at "regular" real-time intervals,
> it seems to assume that regularity will just happen. perhaps it does.

I do wonder who assembled all these tools, I have found enough
mixtures of Plan 9 compatibilities and Posix-isms to cause me
indigestion.  But at this point I only want to eliminate compilation
errors in the Go build procedure under Plan 9, I don't really care if
some tools do not function as required, as long as they are not
essential to the build.

On the other hand, if the tools can be made to work correctly besides
compiling successfully, it will improve the likely acceptance of Go
and that ought to be a good thing.

++L

Re: [9fans] nanosleep()?

[Charles Forsyth]

well, in the particular case of profiling, i suspect you might find
that you can do
a better job by using or adapting some existing Plan 9 facilities for the same.

just take unsuitable things out of the mkfiles, since no other system
is using those.
On 28 October 2011 13:05, Lucio De Re <lucio@proxima.alt.za> wrote:>
On the other hand, if the tools can be made to work correctly besides>
compiling successfully, it will improve the likely acceptance of Go>
and that ought to be a good thing.

Re: [9fans] nanosleep()?

[Lucio De Re]

> just take unsuitable things out of the mkfiles, since no other system
> is using those.

I was discussing with Ron the fact that in the longer term goinstall
ought to supersede both gmake (at last!) and mk, in building Go. I
guess it needs to deal with situations like the present one kind of a
priori.

++L

Re: [9fans] nanosleep()?

[Christopher Nielsen]

Based on golang mailing list discussions, I do believe that the intent
is to have something like goinstall be the build tool for go, but I
could have misinterpreted what I read.

On Fri, Oct 28, 2011 at 07:32, Lucio De Re <lucio@proxima.alt.za> wrote:
>> just take unsuitable things out of the mkfiles, since no other system
>> is using those.
>
> I was discussing with Ron the fact that in the longer term goinstall
> ought to supersede both gmake (at last!) and mk, in building Go. I
> guess it needs to deal with situations like the present one kind of a
> priori.
>
> ++L
>
>
>



--
Christopher Nielsen
"They who can give up essential liberty for temporary safety, deserve
neither liberty nor safety." --Benjamin Franklin
"The tree of liberty must be refreshed from time to time with the
blood of patriots & tyrants." --Thomas Jefferson

Re: [9fans] nanosleep()?

[Lucio De Re]

> For a first pass, you could create a nanosleep for plan 9 that rounds
> to milliseconds and then use sleep()

Sounds like a plan, because the man page for nanosleep() expects the
underlying resolution to be implemented.  The complexities of "does
not interact with signals" can probably be ignored until further
notice for present purposes.  Being able to resume may take a bit of
effort.

++L

Re: [9fans] nanosleep()?

[Charles Forsyth]

what do they do with nanosleep?
perhaps they are simply implementing a profiling system themselves
because the operating system might not provide a suitable one.
perhaps plan 9 could provide a suitable one instead.
perhaps it already does.

Re: [9fans] nanosleep()?

[Lucio De Re]

> what do they do with nanosleep?

Don't know, really.

> perhaps they are simply implementing a profiling system themselves
> because the operating system might not provide a suitable one.

This is Go, so I'm sure they are looking for a uniform approach.  I
guess they looked too hard?

> perhaps plan 9 could provide a suitable one instead.
> perhaps it already does.

It seems that the model is Plan 9's prof, but I don't know this well
enough to be the judge.  Definitely, though, I'm reluctant to submit a
Plan 9 variant as contrary to the way I understand the Go Authors to
operate.

Implementing nanosleep() does not require enormous resolution,
although there are complications.

++L