ruby wish-list

My personal ruby wish-list (for any feedback):


1) the ability to rescue arrays (or some way to rescue multiple classes
without pain), like this:

all_socket_interrupts_array = [SocketError, Errno::EHOSTUNREACH,
Errno::ENETUNREACH]

begin
# stuff
rescue all_socket_interrupts # non ugly, yet precise!

end

2) a GC that is 'user-definable' (run after this definable threshold,
this often), and (asidedbly), a GC that can run in its own (native)
thread so it doesn't pause execution of normal threads.

3) an ensure block that's uninterruptible, a la:

begin
# do stuff
rescue
# rescue stuff
ensure_uninterruptible # (or call it ensure_critical)
# do stuff which is guaranteed to get run, and not interrupted.
end

4) the optional ability to have it display the whole backtrace on
uncaught exceptions (and also for all existing threads).

Guess that's it

Any thoughts?
Thanks.
-Roger
--
Posted via http://www.ruby-forum.com/.

Roger Pack wrote:
> My personal ruby wish-list (for any feedback):
>
>
> 1) the ability to rescue arrays (or some way to rescue multiple classes
> without pain), like this:
>
> all_socket_interrupts_array = [SocketError, Errno::EHOSTUNREACH,
> Errno::ENETUNREACH]
>
> begin
> # stuff
> rescue all_socket_interrupts # non ugly, yet precise!
rescue *all_socket_interrupts_array => e

Should work, I think. At least, it appears to under my brief tests...

--
Alex

Works great thanks Alex!

> > begin
> > # stuff
> > rescue all_socket_interrupts # non ugly, yet precise!
>
> rescue *all_socket_interrupts_array => e
>
> Should work, I think. At least, it appears to under my brief tests...
>
> --
> Alex

Thanks Matz.
Comments on comments:

> |2) a GC that is 'user-definable' (run after this definable threshold,
> |this often), and (asidedbly), a GC that can run in its own (native)
> |thread so it doesn't pause execution of normal threads.
>
> I'd rather prefer smarter collector, but it's possible.

Yeah a smarter collector would be even nicer.

> |ensure_uninterruptible # (or call it ensure_critical)
>
> It's not as simple as you've expected. First we need to define how
> "uninterruptible" section work.

I agree. One definition would be to mark Thread.critical, then runs the
block, then unmark. I would use it

> |4) the optional ability to have it display the whole backtrace on
> |uncaught exceptions (and also for all existing threads).
>
> Simple code like:
>
> begin
> ...
> rescue => e
> puts e.backtrace
> end
>
> would do.
>
> matz.

Good point My suggestions are thinning down quickly
Thanks.
-Roger
--
Posted via http://www.ruby-forum.com/.

On 15.10.2007 17:24, Roger Pack wrote:
>> |ensure_uninterruptible # (or call it ensure_critical)
>>
>> It's not as simple as you've expected. First we need to define how
>> "uninterruptible" section work.
>
> I agree. One definition would be to mark Thread.critical, then runs the
> block, then unmark. I would use it

Bad idea in light of native threads IMHO. Every construct that halts
all threads should be avoided. If you need exclusive access to
resources you need to proper synchronize on them.

> Good point My suggestions are thinning down quickly

:-)

Cheers

robert

On 15.10.2007 18:45, Robert Klemme wrote:
> On 15.10.2007 17:24, Roger Pack wrote:
>>> |ensure_uninterruptible # (or call it ensure_critical)
>>>
>>> It's not as simple as you've expected. First we need to define how
>>> "uninterruptible" section work.
>>
>> I agree. One definition would be to mark Thread.critical, then runs
>> the block, then unmark. I would use it
>
> Bad idea in light of native threads IMHO. Every construct that halts
> all threads should be avoided. If you need exclusive access to
> resources you need to proper synchronize on them.

I meant: in the light of the fact that native threads will come at a
certain point in time. Your suggested feature would make it
unnecessarily complex and slow to use native threads (there would have
to be regular synchronization on some hidden global lock, which defies
the whole purpose of using (native) threads).

robert

I don't really see the reason why the GC would need or want a specific thread to itself - for a start, such a design makes the system slower on low end systems. There may also be cases where it is possible to choose 'optimal' times to run the GC within a single thread context.

One thing regarding the GC I am unsure about are the conditions under which the GC is actually run. One not uncommon problem with external libraries (classic and common example is RMagick) do not malloc using the correct api, Ruby often fails to call the GC, at all.

A call to GC.start under these conditions can prevent an OOME, as calling GC.start does in fact cause RMagick to free memory - but ruby doesn't know about this.

The simplest solution to this issue I can see is to ensure that the GC is run when an OOME occurs, or more particularly, all loaded extensions are told to free when an OOME occurs (this does not seem to happen under these conditions). Whilst I know this is not really the responsibility of Ruby, this simple addition could solve problems for quite a number of scripts, thus removing a FAQ.

More regular GC runs may actually be sensible, depending on the real performance issues that might arise with longer running applications and fragmentation. A documented example of such a problem, and a solution is here: http://zdavatz.wordpress.com/2007/07...-ruby-process/

Robert Klemme wrote:
> On 15.10.2007 18:45, Robert Klemme wrote:
>> On 15.10.2007 17:24, Roger Pack wrote:
>>>> |ensure_uninterruptible # (or call it ensure_critical)
>>>>
>>>> It's not as simple as you've expected. First we need to define how
>>>> "uninterruptible" section work.
>>>
>>> I agree. One definition would be to mark Thread.critical, then runs
>>> the block, then unmark. I would use it
>>
>> Bad idea in light of native threads IMHO. Every construct that halts
>> all threads should be avoided. If you need exclusive access to
>> resources you need to proper synchronize on them.
>
> I meant: in the light of the fact that native threads will come at a
> certain point in time. Your suggested feature would make it
> unnecessarily complex and slow to use native threads (there would have
> to be regular synchronization on some hidden global lock, which defies
> the whole purpose of using (native) threads).
>
> robert
>
>

I agree. Thinking out loud...with a true 'native' threaded model I
don't know if it would be a spectacular idea to be able to block all
threads. I've often wondered how Ruby 1.9 will implement
Thread.critical, at all. If it does attempt to, then maybe this
suggestion (though aimed mostly at 1.8.6) might still be useful (if you
don't mind the possible slowdown). If not then yeah--probably not worth
the hassle

Other suggestions of how ensure_uninterruptable might work (like 'this
thread doesn't accept interruptions [thread_name.raise's] for awhile')
seem like even worse ideas.

The benefit of having such a feature in the first place would be that
you can 'nest' timeouts and other code that executes
other_thread_name.raise, without some dangerous issues cropping up when
two raises occur very close to the same time. Or basically that you can
execute other_thread_name.raise on more complex code without the
drawbacks that might occur.

An example of this is if you nest two timeouts one within another, and
one happens to expire when the other is not finished processing its
ensure block. This will possibly cause a 'random' exception to be
raised on the origin thread later. I guess basically currently the use
of other_thread_name.raise is dangerous, this would help that.

Just my $.02
Thought welcome.
-Roger


Robert Klemme wrote:
> On 15.10.2007 18:45, Robert Klemme wrote:
>> all threads should be avoided. If you need exclusive access to
>> resources you need to proper synchronize on them.
>
> I meant: in the light of the fact that native threads will come at a
> certain point in time. Your suggested feature would make it
> unnecessarily complex and slow to use native threads (there would have
> to be regular synchronization on some hidden global lock, which defies
> the whole purpose of using (native) threads).
>
> robert
--
Posted via http://www.ruby-forum.com/.

So you'd prefer a few tweaks:

> I don't really see the reason why the GC would need or want a specific
> thread to itself - for a start, such a design makes the system slower on
> low end systems. There may also be cases where it is possible to choose
> 'optimal' times to run the GC within a single thread context.

So if it were someday created to run as a separate thread, you'd like to
still be able to have a call 'GC.start.join' or what not, to let it
finish during an 'optimal' time?



>...A call to GC.start under these conditions can prevent an OOME, or more
> particularly, that all loaded extensions
> are told to free when an OOME occurs

And you'd prefer a small change to the GC such that it also starts on
OOME's, correct?


http://zdavatz.wordpress.com/2007/07...-ruby-process/
Wow I hope I never run into any memory issues like that!

Yeah those also sound reasonable
Wish lists have no bias
Take care.
-Roger
--
Posted via http://www.ruby-forum.com/.

Hey!

Not **quite** on topic of garbage collection.... But how hard would
it be to create maybe a style of method creation that doesn't use
the . to represent Object.behavior ?

In retrospect, it seems like definitely a core language feature that
may or may not be impossible to get at... But I figured I'd ask :-)


Also, Is there an easy/hard way to define new %{} style methods? Like
for a Rope object, maybe %m{} or something.

Just a newbie's musings.

Thanks,
Ari
--------------------------------------------|
If you're not living on the edge,
then you're just wasting space.