Mads, Basically, "handle soup" arises from the fact that there are two garbage collectors at work. Handle life cycle is managed by an external VM and its garbage collector, and there is a one-to-many relationship between that VM and isolates. Put another way, there is only one Ruby GC, and it has to work with every Ruby proxy no matter what isolate its handle came from.
That said, I think I have a solution: when a proxy is allocated, it will be passed a reference to the current isolate's disposal queue. That way, if the isolate is disposed of before the handle, it can still be safely enqueued, even though nobody will ever dequeue it. That should work as long as disposing of an isolate will not leak those persistent handles which have not yet been disposed. So for example, how does this behave? https://gist.github.com/1031564 Thanks again for all the replies! cheers, Charles On Jun 16, 1:55 pm, Mads Sig Ager <[email protected]> wrote: > Charles, > > I don't think I understand how you would get into a situation where this is > needed. An object can only be used in the isolate from which it came. So > passing in handles from one isolate to another isolate does not > work. Therefore, the soup of handles from different isolates seems like an > unfortunate situation to get into. If you don't know which isolate a handle > belongs to you cannot use it correctly. > > Cheers, -- Mads > > On Thu, Jun 16, 2011 at 3:55 PM, Charles Lowell > <[email protected]>wrote: > > > > > > > > > Mads, > > > The problem as I see it is not when V8 GC runs, but when Ruby GC runs. > > At that time, I have one heterogeneous list of handles that could > > belong to any number of different isolates. It is then that I would > > like to partition these handles into a bag per isolate. That way, when > > V8 GC runs in the context of each isolate, I can call GetCurrent() and > > dispose of all the handles in that isolate's bag. Does that make more > > sense? > > > Note that I don't actually support multiple isolates at the moment, > > but I do foresee this as a potential problem in the future. > > > On Jun 15, 2:21 am, Mads Sig Ager <[email protected]> wrote: > > > Hi Charles, > > > > when you get the callback you will have to be using that isolate. So > > getting > > > the isolate should be as simple as doing Isolate::GetCurrent() and then > > add > > > the handle to the list for that isolate? > > > > Cheers, -- Mads > > > > On Wed, Jun 15, 2011 at 9:17 AM, Jedrzej Nowacki > > > <[email protected]>wrote: > > > > > Hi, > > > > > You can keep the isolate pointer inside an internal field. Depending > > on > > > > the > > > > handles template type: > > > > > Object::SetInternalField > > > > Script::setData > > > > Context::setData > > > > > Cheers, > > > > Jedrek > > > > > On Tuesday 14. June 2011 22.50.08 ext Charles Lowell wrote: > > > > > Given a persistent handle, is it possible to find out the Isolate > > with > > > > > which it is associated. The reason I say is that I've change > > > > > therubyracer to queue up handles to be released in a single spot > > where > > > > > it is safe to lock V8 (not the Ruby GC thread). When ruby GC sees a > > > > > disposable handle, I'd like to add it to a queue associated with that > > > > > handle's Isolate so that the queue can later be emptied in the scope > > > > > of that Isolate. > > > > > > We don't support multiple Isolates yet, so I can get away with having > > > > > a single queue per Ruby process, but to add support in the future, it > > > > > would make things a easier. Ideas? > > > > > > cheers, > > > > > Charles > > > > > -- > > > > v8-users mailing list > > > > [email protected] > > > >http://groups.google.com/group/v8-users > > > -- > > v8-users mailing list > > [email protected] > >http://groups.google.com/group/v8-users -- v8-users mailing list [email protected] http://groups.google.com/group/v8-users
