Native Threads (was Re: [Cleanup?] Int vs Long)

On Thu, 22 Aug 2002 19:06:15 +0900
Michal Rokos <[e-mail]> wrote:

> 	As I calculated the space needed for this new lock, it could add
> 	about 5 pointers size to every Ruby object, that means: doubles
> 	memory needs! (Current std. Ruby object is about 5 pointers as
> 	well) I'm not sure wether it is acceptable.
> 
> 	Also this could bring a lot of deadlocks and I'm not sure if it
> 	is suitable for eval and parsing part.
> 	====================================
> 
> 	If you will have just 1 global lock, I don't see any benefit of
> 	bringing native threads in.
> 	
> 	So the project has stopped because of lack of discussion.

Hmmm...if it were possible to have a hash that atomically raised an
exception if the setting of a key was done twice, but allowed for
deletes:

	LOCKS = ImmutableKeyHash.new
	LOCKS[obj.id] = 1
	LOCKS[obj.id] = 1 # -> Exception thrown
	LOCKS.delete(obj.id)
	LOCKS[obj.id] = 1

we could keep a list of locked objects, and set it up like so:

    f = File.open("/tmp/foo", "w")
    1.upto(1) { |i|

        ts << NThread.new {

            NThread::Lock(f) { |f|
                f.puts("#{i}")
                f.close
            }
	}
    }

    ts.each { |t|
        t.join
    }

I don't know how feasible such a hash would be.

----------------------------------------------------------------------
| Jim Hranicky, Senior SysAdmin                   UF/CISE Department |
| E314D CSE Building                            Phone [phone] |
| [e-mail]                      http://www.cise.ufl.edu/~jfh |
----------------------------------------------------------------------

"Given a choice between a complex, difficult-to-understand, disconcerting
 explanation and a simplistic, comforting one, many prefer simplistic
 comfort if it's remotely plausible, especially if it involves blaming
 someone else for their problems."
                                                -- Bob Lewis, _Infoworld_