[#8136] Confused exception handling in Continuation Context — "Robert Dober" <robert.dober@...>

Hi all

13 messages 2006/07/06

[#8248] One-Click Installer: MinGW? or VC2005? — "Curt Hibbs" <ml.chibbs@...>

I just posted this to ruby-talk. But I would also like to discuss this

33 messages 2006/07/18
[#8264] Re: One-Click Installer: MinGW? or VC2005? — Charlie Savage <cfis@...> 2006/07/19

From my experience using both tool chains on Windows (for the ruby-prof

[#8266] Re: One-Click Installer: MinGW? or VC2005? — "Curt Hibbs" <ml.chibbs@...> 2006/07/19

Tim, I'm going to top reply since your post was so long. I'm interested in

[#8267] Re: One-Click Installer: MinGW? or VC2005? — Charlie Savage <cfis@...> 2006/07/19

> Tim, I'm going to top reply since your post was so long. I'm interested in

[#8271] my sandboxing extension!! — why the lucky stiff <ruby-core@...>

I have (what feels like) very exciting news. I finally sat down to code up my

17 messages 2006/07/19

[#8430] Re: doc patch: weakref. — "Berger, Daniel" <Daniel.Berger@...>

> -----Original Message-----

19 messages 2006/07/28
[#8434] Re: doc patch: weakref. — Yukihiro Matsumoto <matz@...> 2006/07/29

Hi,

[#8436] Re: doc patch: weakref. — Daniel Berger <djberg96@...> 2006/07/29

Yukihiro Matsumoto wrote:

[#8437] Re: doc patch: weakref. — Mauricio Fernandez <mfp@...> 2006/07/29

On Sat, Jul 29, 2006 at 07:37:24PM +0900, Daniel Berger wrote:

[#8441] Inconsistency in scoping during module_eval? — "Charles O Nutter" <headius@...>

I have the following code:

18 messages 2006/07/30
[#8442] Re: Inconsistency in scoping during module_eval? — nobu@... 2006/07/30

Hi,

[#8443] Re: Inconsistency in scoping during module_eval? — "Charles O Nutter" <headius@...> 2006/07/30

Why does this:

[#8445] Re: Inconsistency in scoping during module_eval? — Yukihiro Matsumoto <matz@...> 2006/07/30

Hi,

[#8454] Re: Inconsistency in scoping during module_eval? — "Charles O Nutter" <headius@...> 2006/07/31

So to clarify...

PTY on Solaris multi-processor systems

From: Reto Schuettel <reto-ruby-core@...>
Date: 2006-07-19 15:20:28 UTC
List: ruby-core #8282
Hi

Yet another problem/bug I'd like to report.

On solaris (Solaris 8 tested) multi-processor systems the pty library
doesn't work properly:
 
| # execute a command which produces some output and sleep for one second 
| # (to avoid triggering the PTY::ChildExited exception)
| so, si, pid = PTY.spawn("hostname; sleep 1") 
| 
| # read some bytes...
| puts so.sysread(1)
| # --> throws EOFError 
| 
| # well.. lets try again, read again (in same process.. )
| puts so.sysread(1)
| # --> able to read the first byte

So, a work-around would be to ignore the first exception, but this can
back-fire if an EOF immediately occurs :/. 

When the process gets bound to a single cpu the above code works as expected. 

| # bind the current process to the first cpu 
| system("pbind -b 0 #{$$}")
| so, si, pid = PTY.spawn("hostname; sleep 1") 
| puts so.sysread(1)
| # --> works

Okay, and there's another error/problem:

This snipped starts and stops many processes. To keep on going I ignore
any PTY::ChildExited Exceptions[1]. As you can see I kill the process
immediately, but usually this would be a normal program termination.

| require 'pty'
| 
| STDOUT.sync = true
| 
| fhs = []
| 
|
| 100.times do |i|
|   begin
|     print "."
|     so, si, pid = PTY.spawn("hostname; sleep 1")
|   
|     sleep 0.1
|     Process.kill("TERM", pid)
|   rescue PTY::ChildExited => e
|     # ignore the exits
|   end
| end

The following thing happens:

.......................pty.rb:10:in `spawn': No such process - can't get Master/Slave device (Errno::ESRCH)
        from pty.rb:10
        from pty.rb:7

After about 20-50 runs ruby complains about not being able to get any
PTY devices. In fact it has eaten up all the remaining pty devices
(solaris seems to limit that, I don't know...) which can even lead to a
system where you can't log in anymore (because the ssh daemon also needs
pty devices). 

Closing the the i/o streams (si & so) manually solves this problem:

| require 'pty'
| 
| STDOUT.sync = true
| 
| fhs = []
| 
| 100.times do |i|
|   si = nil
|   so = nil
|   begin
|     print "."
|     so, si, pid = PTY.spawn("hostname; sleep 1")
|   
|     sleep 0.1
| 
|     Process.kill("TERM", pid)
|   rescue PTY::ChildExited => e
|     # ignore the exits
|   ensure
|     si.close if si; si = nil
|     so.close if so; so = nil
|   end
| end

> $ ruby1.8 pty-close.rb 
> ..................................................................................................
> done

Perhaps this behavior was intended, but at least it should be documented. 


I'm not sure if these errors only occurs on solaris 8, but somehow I doubt
it. I can temporarily provide a Solaris 8 System (SMP) if a developer would
like to work on this problem and doesn't have the hardware.

Regards,
Reto Schuettel

1) These exceptions are so annoying, can't I just ask for the current
status? I.e. RExpect works around this problem by starting another
thread and catching this exception there... but it isn't easy to
implement than when you have to expect an Exception at any time.

In This Thread

Prev Next