[Twisted-Python] Is there pb documentation somewhere?

[Dustin J. Mitchell]

Adding what amounts to a use-after-free bug to the protocol seems like a
really bad idea to me.

Perhaps you see a more compelling use-case than the chess example.  In just
about any case I can think of, I'm not at all concerned about when garbage
collection takes place.  Certainly it opens you to a denial of service from
a malicious client, which might hold references to objects you'd rather it
didn't, but PB's not made for use in hostile situations, and anyway it has
an upper limit (hard-coded to 4096) on the number of references a client
can hold.  Trust me, Buildbot users run up against that limit all the time.

If your server-side app is sensitive to when objects are destroyed for any
reason aside from management of its memory consumption, I'd argue your app
is broken.

It's worth noting that Buildbot also ran into a nasty bug in an older
version of Twisted that caused the broker to not unreference objects
correctly, which led to quite a bit of memory usage.

Dustin



On Mon, Aug 18, 2014 at 8:28 PM, Daniel Sank <sank.daniel at gmail.com> wrote:

> Dustin and glyph,
>
> > Indeed, what you're expecting is very much against the design of PB.
>
> I see. The existing Referenceable code now makes sense to me, since I now
> understand the intent. Thank you.
>
> Would having something like Referenceable but which is not reference
> counted across the network, and which receives a notification when the
> server-side object dies, be useful [1]?
>
> I'm thinking of the case where I use pb to play chess over the network. If
> a piece is captured, the server's reference to that object will be deleted.
> There is no sense, in this case, for the object representing the piece to
> persist, and certainly not because the client's happen to have knowledge
> that the piece existed once upon a time.
>
> Daniel
>
> [1] I haven't delved into the Viewable code yet, so that might be what I'm
> describing.
>
>
>
> On Mon, Aug 18, 2014 at 4:30 PM, Dustin J. Mitchell <dustin at v.igoro.us>
> wrote:
>
>> Indeed, what you're expecting is very much against the design of PB.
>>
>> Dustin
>>
>>
>> On Mon, Aug 18, 2014 at 5:25 PM, Daniel Sank <sank.daniel at gmail.com>
>> wrote:
>>
>>> Dustin,
>>>
>>> > No, this is simply incorrect.  'del myThingy' simply removes
>>> > a reference to the object to which myThingy refers.
>>>
>>> Argh. I'm assuming, as in the example, that the only strong reference to
>>> myThingy is the one I own.
>>>
>>> > the Broker keeps a Python reference to the object internally,
>>> > preventing the reference count from reaching zero,
>>> > preventing the object from being deleted.
>>>
>>> I understand that. I'm trying to ask if that's how it _should_ work. If
>>> I have a resource and make a Referenceable to give you access to it, it
>>> doesn't really make sense to me that my resource should be kept alive just
>>> because you have that access. It seems more reasonable to me that your
>>> access object should reference my resource _weakly_ and that you should
>>> receive some kind of notification if and when the resource expires.
>>>
>>> It's just like the case of a GUI and a business logic object. The GUI
>>> probably gets a reference to the business logic object so that eg. button
>>> pushes can invoke methods on the object. However, that reference should
>>> probably be weak so that the business logic object can be garbage collected
>>> when it's finished with its business. There's no sense (to me) in keeping
>>> an object alive because a GUI, logger, or other observer is observing it.
>>> Am I just wrong?
>>>
>>> Daniel
>>>
>>>
>>> On Mon, Aug 18, 2014 at 2:18 PM, Dustin J. Mitchell <dustin at v.igoro.us>
>>> wrote:
>>>
>>>> On Mon, Aug 18, 2014 at 3:37 PM, Daniel Sank <sank.daniel at gmail.com>
>>>> wrote:
>>>> > and I send you the Referenceable. Now suppose I do
>>>> >
>>>> > del myThingy
>>>> >
>>>> > Now myThingy will be garbage collected.
>>>>
>>>> No, this is simply incorrect.  'del myThingy' simply removes a
>>>> reference to the object to which myThingy refers.
>>>>
>>>> If and only if that's the last reference (as determined by Python's
>>>> reference counting), it is deleted.  As glyph said, as long as there
>>>> is an outstanding remote reference, the Broker keeps a Python
>>>> reference to the object internally, preventing the reference count
>>>> from reaching zero, preventing the object from being deleted.
>>>>
>>>> Dustin
>>>>
>>>> _______________________________________________
>>>> Twisted-Python mailing list
>>>> Twisted-Python at twistedmatrix.com
>>>> http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
>>>>
>>>
>>>
>>>
>>> --
>>> Daniel Sank
>>> Department of Physics
>>> Broida Hall
>>> University of California
>>> Santa Barbara, CA 93117
>>> (805)893-3899
>>>
>>> _______________________________________________
>>> Twisted-Python mailing list
>>> Twisted-Python at twistedmatrix.com
>>> http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
>>>
>>>
>>
>> _______________________________________________
>> Twisted-Python mailing list
>> Twisted-Python at twistedmatrix.com
>> http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
>>
>>
>
>
> --
> Daniel Sank
> Department of Physics
> Broida Hall
> University of California
> Santa Barbara, CA 93117
> (805)893-3899
>
> _______________________________________________
> Twisted-Python mailing list
> Twisted-Python at twistedmatrix.com
> http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/twisted-python/attachments/20140818/a8f1c5a7/attachment-0002.html>