Adding support for z/OS; test TestReadClose fails

[fswarbrick]

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:

--- FAIL: TestReadClose (0.00s)
    io_test.go:80: Unexpected read error: read /dev/ptmx: EDC5112I Resource temporarily unavailable..
panic: Fail in goroutine after TestReadClose has completed

goroutine 35 [running]:
testing.(*common).Fail(0xc001630000)
        /u/dvfjs/.local/usr/go/src/testing/testing.go:952 +0x134
testing.(*common).Errorf(0xc001630000, {0x108503c4, 0x19}, {0xc0016387c8, 0x1, 0x1})
        /u/dvfjs/.local/usr/go/src/testing/testing.go:1075 +0x9e
github.com/creack/pty/v2.TestReadClose.func1()
        /u/dvfjs/diffm/pty/io_test.go:72 +0xf0
created by github.com/creack/pty/v2.TestReadClose in goroutine 17
        /u/dvfjs/diffm/pty/io_test.go:69 +0x192
FAIL    github.com/creack/pty/v2        0.812s
FAIL

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.

[creack]

would you have a way I could try by any chance? Via an IBM service or a running VM?

[creack]

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

[fswarbrick]

would you have a way I could try by any chance? Via an IBM service or a running VM?

Wouldn't that be nice! I am not aware of any freely available z/OS systems. IBM likes their money.

[fswarbrick]

@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.

[creack]

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.

[fswarbrick]

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:

func (mu *fdMutex) rwlock(read bool) bool { 
 var mutexBit, mutexWait, mutexMask uint64  
 var mutexSema *uint32                      
 if read {                                  
  mutexBit = mutexRLock                     
  mutexWait = mutexRWait                    
  mutexMask = mutexRMask                    
  mutexSema = &mu.rsema                     
 } else {                                   
  mutexBit = mutexWLock                     
  mutexWait = mutexWWait                    
  mutexMask = mutexWMask                    
  mutexSema = &mu.wsema                     
 }                                          
 for {                                      
  old := atomic.LoadUint64(&mu.state)       
  if old&mutexClosed != 0 {                 
   return false                             
  }                                         
  [...]

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).

func (fd *FD) readLock() error {
 if !fd.fdmu.rwlock(true) {     
  return errClosing(fd.isFile)  
 }                              
 return nil                     
}                               

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.

[fswarbrick]

Matter is in the hands of the z/OS Go team.