Re: Threads and Ruby


On Jun 30, 2008, at 6:55 PM, Charles Oliver Nutter wrote:


The fact that Ruby's threading has many breakages and pitfalls does
not mean threading in general is the wrong way to fix things. Java
threading works extremely well, with the only real requirement that
you must either synchronize or avoid access to shared resources.
Power...responsibility...etc. You can't damn threading because the
standard implementation of Ruby doesn't do it well.

Perhaps you're right that when you only have access to green threads
that processes are the right way to go, since green threads don't
really gain you anything other than simulated asynchrony. But native
threads done right are as good as separate processes, with the bonus
that you can share fast in-memory access to resources if you're
willing to accept the synchronization cost and complexity.

yeah i agree 100% in principle. however i was programming java when
stopping threads suddenly became depreciated, which i know you know
all about, but for others

http://java.sun.com/j2se/1.4.2/docs/guide/misc/threadPrimitiveDeprecation.html

so doing something as simple as stopping a thread can be complicated.
i can kill a process and all resources will be returned to the
system. the fact that sun took quite a few years to figure this out,
and that matz ruby had the bugs you recently found beg the question:
if matz cannot do exceptions + threads right, if sun cannot get
stopping a thread right for years, what chance do i have of writing
code for, say, a web server that's supposed to run 24x7? i think
modern languages are caving to the reality that most (aka average)
programmers simply cannot program threads safely and are increasingly
moving towards the message passing paradigm ousterhout has been raving
about for years.

now having said that, i very often use ruby threads but often do so in
a message passing fashion and even more often use those threads to
spawn processes and achieve parallelism so i definitely am glad they
are there (Thread.new{ curl } is ultra powerful). still, i can't help
but feel they are destined to become relics - at least in the direct
fashion we use them now.

kind regards.


a @ http://codeforpeople.com/
--
we can deny everything, except that we have the possibility of being
better. simply reflect on that.
h.h. the 14th dalai lama




.

Relevant Pages

  • Re: Probably an FAQ, but...
    ... You referred to 'dedicated' Ruby coders, ... Another person on this list that's been programming a "longish" ... time and is in the intersection of language lawyers (aka people who ... innovations have *led* the formal specifications, ...
    (comp.lang.ruby)
  • Re: Ideas on "Why Living Dangerous can be A Good Thing" in Ruby?
    ... The fear in part has to do with type checking. ... essential to 'safe' programming. ... I personally have never crashed my computer using Ruby. ... just removing the type checking and other 'security' measures. ...
    (comp.lang.ruby)
  • Re: Good Dungeon Mapping e-Tool?
    ... for that, it doesn't extend well to other resources, and isn't ... of late to add it to every programming environment that gets created. ... explicit dispose call even though the GC would clean up the purely ... whether the interface that you're using points to a disposable object ...
    (rec.games.frp.dnd)
  • Re: help a beginner with a basic function that should return a char
    ... are not necessarily great programming practice. ... on the duality the behavior of static variables and those in local scope is ... I don't often have resource problems on modern machines. ... Applications tend to be written as if each user has the resources ...
    (comp.lang.c)
  • Re: teaching ruby as cs intro?
    ... Learning about Ruby has been a way nicer ... > language at an introductory level. ... > students too quickly; nonetheless there's enough documentation on the ... rich std lib and wide range of programming paradigms covered as ...
    (comp.lang.ruby)
Loading