[#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...

Re: PTY on Solaris multi-processor systems

From: nobu@...
Date: 2006-07-20 02:28:00 UTC
List: ruby-core #8301
Hi,

At Thu, 20 Jul 2006 00:20:28 +0900,
Reto Schuettel wrote in [ruby-core:08282]:
> 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 :/. 

Maybe concerned with the timing.  Why do you use sysread?  Does
read_partial also return nil first?

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

It'd be better to retry after GC.


Index: ext/pty/pty.c
===================================================================
RCS file: /cvs/ruby/src/ruby/ext/pty/pty.c,v
retrieving revision 1.26
diff -p -u -2 -r1.26 pty.c
--- ext/pty/pty.c	20 Jun 2006 18:02:14 -0000	1.26
+++ ext/pty/pty.c	20 Jul 2006 00:46:20 -0000
@@ -296,25 +296,24 @@ pty_finalize_syswait(struct pty_info *in
 }
 
-#ifdef HAVE_OPENPTY
+static int
+get_device_once(int *master, int *slave, int fail)
+{
+#if defined HAVE_OPENPTY
 /*
  * Use openpty(3) of 4.3BSD Reno and later,
  * or the same interface function.
  */
-static void
-getDevice(int *master, int *slave)
-{
     if (openpty(master, slave, SlaveName,
 		(struct termios *)0, (struct winsize *)0) == -1) {
+	if (!fail) return -1;
 	rb_raise(rb_eRuntimeError, "openpty() failed");
     }
-}
-#else /* HAVE_OPENPTY */
-#ifdef HAVE__GETPTY
-static void
-getDevice(int *master, int *slave)
-{
+
+    return 0;
+#elif defined HAVE__GETPTY
     char *name;
 
     if (!(name = _getpty(master, O_RDWR, 0622, 0))) {
+	if (!fail) return -1;
 	rb_raise(rb_eRuntimeError, "_getpty() failed");
     }
@@ -322,9 +321,7 @@ getDevice(int *master, int *slave)
     *slave = open(name, O_RDWR);
     strcpy(SlaveName, name);
-}
+
+    return 0;
 #else /* HAVE__GETPTY */
-static void
-getDevice(int *master, int *slave)
-{
     int	 i,j;
 
@@ -351,5 +348,5 @@ getDevice(int *master, int *slave)
 				*slave = j;
 				strcpy(SlaveName, pn);
-				return;
+				return 0;
 #if defined I_PUSH && !defined linux
 			    }
@@ -362,5 +359,6 @@ getDevice(int *master, int *slave)
 	close(i);
     }
-    rb_raise(rb_eRuntimeError, "can't get Master/Slave device");
+    if (!fail) rb_raise(rb_eRuntimeError, "can't get Master/Slave device");
+    return -1;
 #else
     char **p;
@@ -376,14 +374,23 @@ getDevice(int *master, int *slave)
 		chown(SlaveName, getuid(), getgid());
 		chmod(SlaveName, 0622);
-		return;
+		return 0;
 	    }
 	    close(i);
 	}
     }
-    rb_raise(rb_eRuntimeError, "can't get %s", SlaveName);
+    if (fail) rb_raise(rb_eRuntimeError, "can't get %s", SlaveName);
+    return -1;
 #endif
+#endif
+}
+
+static void
+getDevice(int *master, int *slave)
+{
+    if (get_device_once(master, slave, 0)) {
+	rb_gc();
+	get_device_once(master, slave, 1);
+    }
 }
-#endif /* HAVE__GETPTY */
-#endif /* HAVE_OPENPTY */
 
 static void


-- 
Nobu Nakada

In This Thread