[#7809] uninit bug in yaml/emitter.c — "Pat Eyler" <rubypate@...>
During our hacking night, we also looked at an UNINIT bug in yaml/emitter.c
[#7813] :!~ not a symbol — noreply@...
Bugs item #4344, was opened at 2006-05-03 17:41
[#7818] (security-related) patch to ALLOC macros to prevent integer overflow bugs — "Dominique Brezinski" <dominique.brezinski@...>
While fixing the integer overflow in rb_ary_fill(), it occurred to me
[#7833] segfault on Proc#call after setting a trace_func — Mauricio Fernandez <mfp@...>
$ cat bug2.rb
[#7843] Possible YAMl bug in 1.8.4 — Damphyr <damphyr@...>
OK, while parsing the td2 data from the ruby-lang website we stumbled on
Its probably a bug. I'm not familiar with the specifics, but Ruby
[#7858] Ruby threads working with native threads — "Francis Cianfrocca" <garbagecat10@...>
I recently wrote a network-event extension for Ruby ("eventmachine" in
[#7865] Strange interactions between Struct and 'pp' — noreply@...
Bugs item #4457, was opened at 2006-05-12 17:13
[#7872] Nonblocking socket-connect — "Francis Cianfrocca" <garbagecat10@...>
All, I needed a nonblocking socket connect for my asynchronous-event
In article <3a94cf510605140559l7baa0205le341dac4f47d424b@mail.gmail.com>,
How about introducing the method Socket#set_nonblocking, or alternatively
Hi,
Well, it's ok then. I'm comfortable adding in the nonblocking
Hi,
How about Socket#nbconnect and Socket#nbaccept?
On 5/15/06, Francis Cianfrocca <garbagecat10@gmail.com> wrote:
In article <1147709691.180288.28647.nullmailer@x31.priv.netlab.jp>,
[#7881] Segfault on x86_64 when built with -O0 in CFLAGS — noreply@...
Bugs item #4491, was opened at 2006-05-16 12:46
[#7882] reproducible bug in DRb on OSX — cremes.devlist@...
I've been tearing my hair out the last few days trying to track down
[#7909] SCRIPT_LINES__ issue when loading a file more than once — Mauricio Fernandez <mfp@...>
SCRIPT_LINES__ is an obscure feature very few people care about, but I happen
On Fri, May 19, 2006 at 06:46:05PM +0900, Mauricio Fernandez wrote:
Hi,
[#7923] Nonblocking accept — "Francis Cianfrocca" <garbagecat10@...>
Thanks to the Matz and colleagues for adding the *_nonblock functions. They
[#7928] set_trace_func: binding has wrong self value for return events — =?ISO-8859-15?Q?Florian_Gro=DF?= <florgro@...>
Moin.
Florian Growrote:
Re: Nonblocking socket-connect
How about introducing the method Socket#set_nonblocking, or alternatively
Socket#blocking( boolean)? A call to Socket#blocking( true ) would
*explicitly* change the behavior of calls like #connect, #accept, #read and
#write. It would still be possible for programmers to say:
require 'fcntl'
m = socket.fcntl(Fcntl::F_GETFL, 0)
socket.fcntl(Fcntl::F_SETFL, Fcntl::O_NONBLOCK | m)
but this code would preserve the behavior that exists today. (That is, it
would affect the behavior of syswrite and sysread, but not of read, write,
connect, and accept).
In other words, if we call Socket#nonblocking(true), the behavior of
Socket#connect would change to a pure nonblocking behavior. But it would not
break any existing code, nor would it introduce of ugly new method names
(connect_nonblocking, read_nonblocking, write_nonblocking). Calling
Socket#nonblocking( false ) would revert to the original behavior.
On 5/14/06, Tanaka Akira <akr@m17n.org> wrote:
>
> In article <3a94cf510605140559l7baa0205le341dac4f47d424b@mail.gmail.com>,
> "Francis Cianfrocca" <garbagecat10@gmail.com> writes:
>
> > All, I needed a nonblocking socket connect for my asynchronous-event
> > framework, and I notice that ruby_connect blocks the calling thread with
> > wait_connectable. I solved my problem with this (eliding some
> error-checking
> > and platform-specific branches):
> >
> > static VALUE
> > sock_connect_nonblocking (self, addr)
> > VALUE self, addr;
> > {
>
> I think it's good idea to introduce new nonblocking methods.
> However no one propose a method name matz accept, yet.
> --
> Tanaka Akira
>
>