Adding support for z/OS; test TestReadClose fails #197
Replies: 3 comments 4 replies
-
|
would you have a way I could try by any chance? Via an IBM service or a running VM? |
Beta Was this translation helpful? Give feedback.
-
|
Maybe mapping to errClosed would work, but make sure that EAGAIN make sense here. Once one side of the master/slave is closed, I wouldn't expect the error to be temporary as re-opening would yield a new fd which may be different from the old one. Maybe z/OS works differently and allows re-open the master side? You understood correctly the intent of the test. Unblock a Read call by calling Close. This test only makes sense in a non-blocking environment though, which is disabled on darwin. Maybe z/OS would be similar? https://github.com/creack/pty/blob/master/io_test.go#L93-L96 |
Beta Was this translation helpful? Give feedback.
-
Wouldn't that be nice! I am not aware of any freely available z/OS systems. IBM likes their money. |
Beta Was this translation helpful? Give feedback.
-
|
@creack, do you know how I might emulate the TestReadClose test using C? I'd like to see if it gets the same result, but I'm not sure how a child process can close a parent fd/file. |
Beta Was this translation helpful? Give feedback.
-
|
Not sure to follow. It is not the child process closing a parent fd, it is the parent reading on one goroutine (in C you can use a thread) and closing on another goroutine (or thread). So to reproduce in C, you could do something very similar as the test code in Go. Start a pty in nonblock mode, read from in in one thread and close it from another. |
Beta Was this translation helpful? Give feedback.
-
|
So I think I know where the issue is. But it's in the go runtime itself. In go/src/internal/poll/fd_mutex.go we have method rwlock: On Linux, when the method is entered, mu.state == 0x0, but by the time it gets to the first line of rwlock, the state has been updated to 0x1 (asynchronously, I assume). So when it checks old&mutextClosed, that returns 0x1 and causes the method to return false. The causes readLock (below) to return errClosing(fd.isFile). Then of course this error gets passed back through the read. With z/OS the state is not changing from 0x0 to 0x1, so the errClosing return never executes. I have an in to the Go for z/OS maintainers, so I will bring the issue to them. |
Beta Was this translation helpful? Give feedback.
-
|
Matter is in the hands of the z/OS Go team. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
z/OS is a POSIX compliant operating system for IBM mainframes. I've been 99(?)% successful in adding z/OS support to this pty package. I am getting one error using "go test", as follows:
The associated C errno seems to be EAGAIN.
While I think I can see what it's trying to do, allow an asynchronous close to unblock (I think) a blocked read, I'm not sure what I am supposed to get as the correct result. Do I need to map the error I am receiving to os.ErrClosed? Or something else?
Thanks for any assistance.
Beta Was this translation helpful? Give feedback.
All reactions