[#61171] Re: [ruby-changes:33145] normal:r45224 (trunk): gc.c: fix build for testing w/o RGenGC — SASADA Koichi <ko1@...>
(2014/03/01 16:15), normal wrote:
3 messages
2014/03/01
[#61243] [ruby-trunk - Feature #9425] [PATCH] st: use power-of-two sizes to avoid slow modulo ops — normalperson@...
Issue #9425 has been updated by Eric Wong.
4 messages
2014/03/03
[#61359] [ruby-trunk - Bug #9609] [Open] [PATCH] vm_eval.c: fix misplaced RB_GC_GUARDs — normalperson@...
Issue #9609 has been reported by Eric Wong.
5 messages
2014/03/07
[#61360] Re: [ruby-trunk - Bug #9609] [Open] [PATCH] vm_eval.c: fix misplaced RB_GC_GUARDs
— SASADA Koichi <ko1@...>
2014/03/07
(2014/03/07 19:09), [email protected] wrote:
[#61362] Re: [ruby-trunk - Bug #9609] [Open] [PATCH] vm_eval.c: fix misplaced RB_GC_GUARDs
— Eric Wong <normalperson@...>
2014/03/07
SASADA Koichi <[email protected]> wrote:
[#61424] [REJECT?] xmalloc/xfree: reduce atomic ops w/ thread-locals — Eric Wong <normalperson@...>
I'm unsure about this. I _hate_ the extra branches this adds;
13 messages
2014/03/12
[#61466] Re: [REJECT?] xmalloc/xfree: reduce atomic ops w/ thread-locals
— SASADA Koichi <ko1@...>
2014/03/13
Hi Eric,
[#61471] Re: [REJECT?] xmalloc/xfree: reduce atomic ops w/ thread-locals
— Eric Wong <normalperson@...>
2014/03/13
SASADA Koichi <[email protected]> wrote:
[#61508] Re: [REJECT?] xmalloc/xfree: reduce atomic ops w/ thread-locals
— SASADA Koichi <ko1@...>
2014/03/15
(2014/03/14 2:12), Eric Wong wrote:
[#61509] Re: [REJECT?] xmalloc/xfree: reduce atomic ops w/ thread-locals
— Eric Wong <normalperson@...>
2014/03/15
SASADA Koichi <[email protected]> wrote:
[#61510] Re: [REJECT?] xmalloc/xfree: reduce atomic ops w/ thread-locals
— SASADA Koichi <ko1@...>
2014/03/15
(2014/03/15 17:34), Eric Wong wrote:
[#61452] [ruby-trunk - Feature #9632] [Open] [PATCH 0/2] speedup IO#close with linked-list from ccan — normalperson@...
Issue #9632 has been reported by Eric Wong.
3 messages
2014/03/13
[#61496] [ruby-trunk - Feature #9638] [Open] [PATCH] limit IDs to 32-bits on 64-bit systems — normalperson@...
Issue #9638 has been reported by Eric Wong.
4 messages
2014/03/14
[#61568] hash function for global method cache — Eric Wong <normalperson@...>
I came upon this because I noticed existing st numtable worked poorly
7 messages
2014/03/17
[#61605] Re: hash function for global method cache
— SASADA Koichi <ko1@...>
2014/03/20
(2014/03/18 8:03), Eric Wong wrote:
[#61606] Re: hash function for global method cache
— Eric Wong <normalperson@...>
2014/03/20
SASADA Koichi <[email protected]> wrote:
[#61631] Re: hash function for global method cache
— =?KOI8-R?B?4NLJyiDzz8vPzM/X?= <funny.falcon@...>
2014/03/22
what's the profit from using binary tree in place of hash?
[#61632] Re: hash function for global method cache
— Eric Wong <normalperson@...>
2014/03/22
Юрий Соколов <[email protected]> wrote:
[#61687] [ruby-trunk - Bug #9606] Ocassional SIGSEGV inTestException#test_machine_stackoverflow on OpenBSD — normalperson@...
Issue #9606 has been updated by Eric Wong.
3 messages
2014/03/26
[#61760] [ruby-trunk - Feature #9632] [PATCH 0/2] speedup IO#close with linked-list from ccan — normalperson@...
Issue #9632 has been updated by Eric Wong.
3 messages
2014/03/30
[ruby-core:61412] [ruby-trunk - Bug #9617] Windows7 issue with Kernel.spawn close_others => false
From:
usa@...
Date:
2014-03-11 11:43:39 UTC
List:
ruby-core #61412
Issue #9617 has been updated by Usaku NAKAMURA.
Lionel PERRIN wrote:
> * Is there a technical reason why it is not supported ?
>
> I've looked at the ruby source code. From my understanding, the CreateProcess call is made with inheritHandles set to true, which should make possible to transfer handles. Nevertheless, CreatePipe call is made in a way that forbid this handle to be inherited. Wouldn't it be possible to change this ?
We do not have a way how specify which handle corresponds to which file descriptor to a child process.
First of all, we do not know whether a child process treats file descriptors or not.
> * Wouldn't it be worth updating the documentation ? It is not specified that the Kernel.spawn command is limited on windows.
I think so, too.
----------------------------------------
Bug #9617: Windows7 issue with Kernel.spawn close_others => false
https://bugs.ruby-lang.org/issues/9617#change-45722
* Author: Lionel PERRIN
* Status: Rejected
* Priority: Normal
* Assignee:
* Category: platform/mingw
* Target version:
* ruby -v: ruby 2.0.0p451 (2014-02-24) [i386-mingw32]
* Backport: 1.9.3: UNKNOWN, 2.0.0: UNKNOWN, 2.1: UNKNOWN
----------------------------------------
I faced an issue while trying to inherit a file or pipe handle from a master process to its child on windows 7.
I tried this implementation:
* master.rb:
~~~
rd, wr = IO.pipe
puts "Pipe opened: #{rd.fileno} <= #{wr.fileno}"
cmd = "ruby child.rb #{rd.fileno}"
pid = Kernel.spawn cmd, :close_others => false
wr.write "Hello World\n"
Process.wait pid
~~~
* child.rb:
~~~
puts "Child:Start #{ARGV}"
rd = IO.new(ARGV[0].to_i, mode: "r")
puts rd.read
~~~
On windows I get the following output while it works fine on linux.
~~~
Pipe opened: 3 <= 4
Child:Start ["3"]
child.rb:2:in `initialize': Bad file descriptor (Errno::EBADF)
from child.rb:2:in `new'
from child.rb:2:in `<main>'
~~~
Note: the same test with the fileno of a file opened from master.rb lead to the same exception in child.rb
--
http://bugs.ruby-lang.org/