(Cross-posting from the other discussion.) If someone with a Windows machine in California could run ...
13 years, 11 months ago
(2011-08-25 16:05:33 UTC)
#2
(Cross-posting from the other discussion.)
If someone with a Windows machine in California
could run
package main
import (
"fmt"
"syscall"
)
func main() {
var i syscall.Timezoneinformation
syscall.GetTimeZoneInformation(&i)
fmt.Printf("%#v\n", i)
}
and send me the output, I will paste it into
zoneinfo_windows.go. Thanks.
INSTALL FAIL time make[1]: Entering directory `c:/tzwin/src/pkg/time' make[1]: Leaving directory `c:/tzwin/src/pkg/time' make[1]: *** No rule ...
13 years, 11 months ago
(2011-08-25 17:29:17 UTC)
#8
INSTALL FAIL time
make[1]: Entering directory `c:/tzwin/src/pkg/time'
make[1]: Leaving directory `c:/tzwin/src/pkg/time'
make[1]: *** No rule to make target `sys_windows.go', needed by `_go_.8'. Stop.
here's sys_windows.go. i think this CL is too complicated for hg clpatch to get right. ...
13 years, 11 months ago
(2011-08-25 17:36:42 UTC)
#9
here's sys_windows.go.
i think this CL is too complicated
for hg clpatch to get right.
// Copyright 2011 The Go Authors. All rights reserved.
// Use of this source code is governed by a BSD-style
// license that can be found in the LICENSE file.
package time
import (
"os"
"syscall"
)
func sysSleep(t int64) os.Error {
errno := syscall.Sleep(t)
if errno != 0 && errno != syscall.EINTR {
return os.NewSyscallError("sleep", errno)
}
return nil
}
// for testing: whatever interrupts a sleep
func interrupt() {
}
Cool, thanks. This is progress. It looks like maybe the Windows time zone code has ...
13 years, 11 months ago
(2011-08-25 18:09:32 UTC)
#11
Cool, thanks. This is progress.
It looks like maybe the Windows time zone
code has always done this?
The zone name you sent me was definitely
'Pacific Standard Time' etc but the code
wants 'PST'. I wonder if we can get the
short version out of the Windows system call?
Russ
On Thu, Aug 25, 2011 at 14:22, <go.peter.90@gmail.com> wrote: > Right. If you use the ...
13 years, 11 months ago
(2011-08-25 18:24:48 UTC)
#13
On Thu, Aug 25, 2011 at 14:22, <go.peter.90@gmail.com> wrote:
> Right. If you use the abbreviations, everything works.
Cool. The part I'm worried about is that if you're
actually running real code (not gotest) then you
get what the system gives you, and if that is
"Pacific Standard Time", then things trying to
print "PST" are going to be unhappy.
Russ
Submit this CL using the abbreviation and leaving the full name as a comment. It ...
13 years, 11 months ago
(2011-08-25 18:49:31 UTC)
#14
Submit this CL using the abbreviation and leaving the full name as a comment. It
represents substantial forward progress.
There is no official standard for time zone abbreviations. For example, they are
not unique. For EST. are you in New York or Sidney? For CST are you in Chicago
or China? Therefore Windows, doesn't use them; it uses 32-character string time
zone identifiers and names. Unhappy folks should complain to Microsoft, but they
won't get anywhere.
On Thu, Aug 25, 2011 at 14:49, <go.peter.90@gmail.com> wrote: > Submit this CL using the ...
13 years, 11 months ago
(2011-08-25 18:56:17 UTC)
#15
On Thu, Aug 25, 2011 at 14:49, <go.peter.90@gmail.com> wrote:
> Submit this CL using the abbreviation and leaving the full name as a
> comment. It represents substantial forward progress.
>
> There is no official standard for time zone abbreviations. For example,
> they are not unique. For EST. are you in New York or Sidney? For CST are
> you in Chicago or China? Therefore Windows, doesn't use them; it uses
> 32-character string time zone identifiers and names. Unhappy folks
> should complain to Microsoft, but they won't get anywhere.
It's a bit weird to submit something that only works
in testing but not in real life. Any tools that call
time.Format and expect an abbreviation back
(even if an ambiguous one) are going to be surprised.
Maybe the right fix for now is to just take the
capital letters?
Russ
On 2011/08/25 18:56:17, rsc wrote: > Maybe the right fix for now is to just ...
13 years, 11 months ago
(2011-08-25 19:22:58 UTC)
#16
On 2011/08/25 18:56:17, rsc wrote:
> Maybe the right fix for now is to just take the
> capital letters?
You could do that, and document it. The tzdata key and the abbreviated Windows
name may differ. Windows programmers won't get what they expect. There is no
right answer.
Dates, Times, and Time Zones
http://msdn.microsoft.com/en-us/library/bb384268.aspx
> You could do that, and document it. The tzdata key and the abbreviated > ...
13 years, 11 months ago
(2011-08-25 19:38:37 UTC)
#17
> You could do that, and document it. The tzdata key and the abbreviated
> Windows name may differ. Windows programmers won't get what they expect.
> There is no right answer.
Thanks. I've changed zoneinfo_windows.go and
uploaded a new copy.
Russ
On Thu, Aug 25, 2011 at 16:47, <go.peter.90@gmail.com> wrote: > I'm still having the problem ...
13 years, 11 months ago
(2011-08-25 20:50:01 UTC)
#19
On Thu, Aug 25, 2011 at 16:47, <go.peter.90@gmail.com> wrote:
> I'm still having the problem with sys_windows.go. Is sys_posix.Go being
> renamed before it's copied?
probably. if you want to dig into
hgpatch you're welcome to try to fix it,
but i am happy to leave things be.
the actual submit will use hg directly
so it will not have this problem.
> http://codereview.appspot.com/4968041/diff/8010/src/pkg/time/sys_windows.go#newcode21 > src/pkg/time/sys_windows.go:21: func interrupt() { > TestSleep passes on windows now. But interrupt ...
13 years, 11 months ago
(2011-08-26 00:34:58 UTC)
#24
>
http://codereview.appspot.com/4968041/diff/8010/src/pkg/time/sys_windows.go#n...
> src/pkg/time/sys_windows.go:21: func interrupt() {
> TestSleep passes on windows now. But interrupt function does nothing on
windows.
> So I wander what are we testing, and what is the point of calling of
Interrupt()
> during TestSleep? I commented out syscall.Kill inside of linux version of
> interrupt and it passes too. It can't be right.
if duration < delay {
is inverse.(probably)
And I'll add the code of interrupt() in another CL.
I'm finding way to implement to interrupt sleep via interrupt on windows. The candidates for ...
13 years, 11 months ago
(2011-08-26 02:50:32 UTC)
#25
I'm finding way to implement to interrupt sleep via interrupt on windows.
The candidates for implement are using SleepEx/QueueUserAPC.
But QueueUserAPC require thread handle to notify the completion. So the code
will be following.
----------------------------------------
var mu sync.Mutex
var th []syscall.Handle
func sysSleep(t int64) os.Error {
mu.Lock()
th[syscall.GetCurrentThread()] = true
mu.Unlock()
defer func() {
mu.Lock()
th[syscall.GetCurrent] = false, false
mu.Unlock()
}()
errno := syscall.SleepEx(t, true)
if errno != 0 && errno != syscall.EINTR {
return os.NewSyscallError("sleep", errno)
}
return nil
}
// for testing: whatever interrupts a sleep
func interrupt() {
mu.Lock()
// call QueueUserAPC() to each threads in th.
defer mu.Unlock()
}
----------------------------------------
This seems very adhoc and redundancy to me. it must use SleepEx not Sleep.
Also define syscall.GetCurrentThread(). And it must handle all thread
handles while calling SleepEx().
There is easy way to do same using chan or WaitGroup (i'm not sure).
I suspect to implement pseudo sysSleep/interrupt without using syscall.XXX.
rsc I noticed that SleepEx/QueueUserAPC should be called from each other threads. If calling from ...
13 years, 11 months ago
(2011-08-26 11:26:42 UTC)
#26
rsc
I noticed that SleepEx/QueueUserAPC should be called from each other threads.
If calling from goroutine(meaning same thread), QueueUserAPC succeeded but not
succeeded to interrupt sleep.
Then I've just gave up to use SleepEx/QueueUserAPC. So I changed implement
of that with using CreateEvent/SetEvent/WaitForSingleObject.
----------------------
package time
import (
"os"
"syscall"
"sync"
)
var mu sync.Mutex
var event = make(map[syscall.Handle]bool)
func sysSleep(t int64) os.Error {
ev, _ := syscall.CreateEvent(nil, false, false, nil)
mu.Lock()
event[ev] = true
mu.Unlock()
defer func() {
mu.Lock()
event[ev] = false, false
mu.Unlock()
}()
er, errno := syscall.WaitForSingleObject(ev, uint32((t + 1e6 - 1) / 1e6))
if errno != 0 {
return os.NewSyscallError("sleep", errno)
}
if er == syscall.WAIT_OBJECT_0 {
return os.NewSyscallError("sleep", syscall.EINTR)
}
return nil
}
// for testing: whatever interrupts a sleep
func interrupt() {
for h, _ := range event {
syscall.SetEvent(h)
}
}
----------------------
This may NOT be real Sleep implement, however if you accept,
I'll post this to new CL after the submit of 4968041.
Thanks.
On Thu, Aug 25, 2011 at 20:25, <alex.brainman@gmail.com> wrote: > TestSleep passes on windows now. ...
13 years, 11 months ago
(2011-08-26 19:11:48 UTC)
#27
On Thu, Aug 25, 2011 at 20:25, <alex.brainman@gmail.com> wrote:
> TestSleep passes on windows now. But interrupt function does nothing on
> windows. So I wander what are we testing, and what is the point of
> calling of Interrupt() during TestSleep? I commented out syscall.Kill
> inside of linux version of interrupt and it passes too. It can't be
> right.
TestSleep is checking that (1) sleep sleeps for long enough
and (2) it does so even if the process gets interrupted in the
middle (it should sleep again).
If you take out the interrupt, you're no longer checking (2),
so you've essentially turned off that part of the test.
That's why it still passes.
Russ
Issue 4968041: code review 4968041: time: fix zone during windows test
(Closed)
Created 13 years, 11 months ago by rsc
Modified 13 years, 11 months ago
Reviewers:
Base URL:
Comments: 5