EventMessageSend weakness

Blair,

I think I got to the bottom of my recent bug: I found myself serializing
EventMessageSend instances, and the in-filed instances were apparently doing
push-ups<g> or something while in limbo:

( Object fromBinaryStoreBytes:EventMessageSend new binaryStoreBytes ) isWeak

Since this happens in only one niche in my code, I was able to patch it with
a #beWeak in the right spot vs. establishing an STB proxy to do the fixup;
that seems like something that should be done in the base system if it's
going to be done at all.  It's such a rare situation that I'm pretty happy
with my current hack.

D5 changed EventMessageSend to a variable vs. pointer class.  Was that to
allow weakness in the "messages" part of message sends?  Did D4 have an
event system that held objects it should not have, or did it solve the
problem some other way?  I'm interested only because I'm trying to determine
whether the bug in question was new or simply newly logged, and possibly
whether or not I have more digging to do.

Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]

"Bill Schwab" <[hidden email]> wrote in message
news:b0r9uu$sch6o$[hidden email]...
>
> I think I got to the bottom of my recent bug: I found myself serializing
> EventMessageSend instances, and the in-filed instances were apparently
doing
> push-ups<g> or something while in limbo:
>
> ( Object fromBinaryStoreBytes:EventMessageSend new binaryStoreBytes )
isWeak
>
> Since this happens in only one niche in my code, I was able to patch it
with
> a #beWeak in the right spot vs. establishing an STB proxy to do the fixup;
> that seems like something that should be done in the base system if it's
> going to be done at all.  It's such a rare situation that I'm pretty happy
> with my current hack.

The event system was not designed to be saved/restored with STB. This
doesn't necessarily mean one shouldn't do that, it just means that no
thought was given to it. In particular all objects that provide their own
event storage ensure that the events are not saved out when they themselves
are STB'd.

There is a general issue over STB with weak objects. Probably the weakness
should be restored, although the timing of this is critical so that
premature loss of referenced objects does not occur. I don't know how it
would work out in practice if STB restored weak objects as weak, but at the
moment it is an application responsibility to turn that back on at the
appropriate point.

> D5 changed EventMessageSend to a variable vs. pointer class.  Was that to
> allow weakness in the "messages" part of message sends?

No, it was to allow the receiver to be stored in an indexed slot, and thus
be weakly referenced.

>...Did D4 have an
> event system that held objects it should not have, or did it solve the
> problem some other way?  I'm interested only because I'm trying to
determine
> whether the bug in question was new or simply newly logged, and possibly
> whether or not I have more digging to do.

D4 (and earlier) had to copy the receiver out of the EventMessageSend into
an external weak array, and then nil out the receiver in the
EventMessageSend. This was an inefficient and messy implementation that
precluded the use of other valuables in the events collection.

Regards

Blair

Blair,

> The event system was not designed to be saved/restored with STB.

Understood - and understandable.


> There is a general issue over STB with weak objects. Probably the weakness
> should be restored, although the timing of this is critical so that
> premature loss of referenced objects does not occur. I don't know how it
> would work out in practice if STB restored weak objects as weak, but at
the
> moment it is an application responsibility to turn that back on at the
> appropriate point.

That's what I'm doing now, and it will probably be sufficient as-is.


> D4 (and earlier) had to copy the receiver out of the EventMessageSend into
> an external weak array, and then nil out the receiver in the
> EventMessageSend. This was an inefficient and messy implementation that
> precluded the use of other valuables in the events collection.

Playing(??<g>) dumb here, you are saying that D4 did in fact solve the
problem, just a different way, right?  That is consistent with the resulting
bug being new to my D5 apps, which didn't appear until September or so, and
I started noticing it shortly after that.  Sounds like we might have a
winner.

Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]

"Bill Schwab" <[hidden email]> wrote in message
news:b1631m$ucjn4$[hidden email]...
>
> > D4 (and earlier) had to copy the receiver out of the EventMessageSend
into
> > an external weak array, and then nil out the receiver in the
> > EventMessageSend. This was an inefficient and messy implementation that
> > precluded the use of other valuables in the events collection.
>
> Playing(??<g>) dumb here, you are saying that D4 did in fact solve the
> problem, just a different way, right?  That is consistent with the
resulting
> bug being new to my D5 apps, which didn't appear until September or so,
and
> I started noticing it shortly after that.  Sounds like we might have a
> winner.

Yes, D4 did solve the problem (that of keeping event registrations weak) in
a different way.

Regards

Blair