On Thu, 27 Dec 2018 13:26:19 -0500 Mike Blumenkrantz
said:
> Hi,
>
> Thanks for taking the time to look into this issue. There's been an amount
> of discussion and back-and-forth patching related to it for some time now,
> and it's great to see someone taking some initiative here.
>
> Looking over this patch, I'm unsure whether the method used for resolving
> the issue is indeed the optimal one. Given the already-existing discussion
indeed my log comments question the original commit idea - but i thought this
was a bit better than reverting since i had found a non-revert fix. my take is
that "wrapping" eina promise like this is kind of problematic as it means we
now have some "forbidden" calls that are needed to do the wrapping properly
(the ones i added).
> going on related to this topic, I think this is a patch which would have
> benefited from review prior to being landed. In particular, I'd have
> suggested that unit tests be added for this case--we have somewhat
it's still up in the air as to if this is the right way in the end - but i'm
not sure how that helps as these are "public api's" only in as much as we need
them internally but due to having multiple libraires ... we need to expose
them. the documentation reflects that.
there comes a point where you have to weigh up time vs effort. in this case
the time spent adding tests for an internal use case is not worth it IMHO. time
is a limited resource. i don't see how testing these api's in unit tests will
improve things - they are used already within efl.
> extensive tests for promise usage already, so having a good test case like
> this would improve the reliability of future changes to corresponding
> codepaths--which should not be too difficult given the time that you've
> already invested in debugging the issue to fully understand it.
since i understand it, i don't see what tests are going to do here that isn't
already done within efl.
> I'm constructing this mail from scratch since it looks like you pushed this
> from a branch without resetting the commit date and prevented a mail from
> being sent to the list, so please excuse any strange formatting in the
> patch diff below.
eh? ummm... nope. i did it from master. i had to do some jumping through
hoops with conflicts due to the revert breaking my fixes... ? i actually had
done the fix a few days earlier and was still testing/using it. i ended up
having to modify it due to the conflicts thus date moved forward a few days.
>
> Regards,
> Mike
>
> > commit de2ec0559b01dba7919503955cc47c1c5fcd0f97
> > Author: Carsten Haitzler (Rasterman)
> > Date: Tue Dec 25 13:00:38 2018 +
> >
> > fix crashes created by "make efl_loop_promise_new a function"
> >
> > commit 9b5155c9f135f9ef450a817979f5884352b2d4c0 brought about crashes
> > - specifically that i saw in terminology because it actually uses
> > eina_promise_data_set() and the new efl_loop_promise_new basically
> > took over ownership of that data, but if anyone used
> > eina_promise_data_set() the data ptr used by this new code would bwe
> > overwritten, causing segfauls when terminology loses selection
> > ownership. for days i had mysterious crashes of terminology until i
> > narrowed it down to the above, so if you have too, then this will fix
> > it.
> >
> > what this does is create a data set intercept function callback that
> > for now is only for use inside efl to everride data sets so they set
> > data inside the new struct that tracks data. i also had to add and
> > intercept for eina_promise_data_free_cb_set() as this in theory could
> > also ber a similar problem.
> >
> > so perhaps the idea/design of efl_loop_promise_new() is not right and
> > this kind of thgn has to be internal to eina promise... this means
> > eina promise and loops are much more tied together.
> >
> > diff --git a/src/lib/ecore/efl_loop_consumer.c
> b/src/lib/ecore/efl_loop_consumer.c
> > index 29e94ed52d..1e49bc32aa 100644
> > --- a/src/lib/ecore/efl_loop_consumer.c
> > +++ b/src/lib/ecore/efl_loop_consumer.c
> > @@ -50,4 +50,68 @@ _efl_loop_consumer_future_rejected(Eo *obj,
> Efl_Loop_Consumer_Data *pd EINA_UNUS
> > return eina_future_rejected(efl_loop_future_scheduler_get(obj),
> error);
> > }
> >
> > +typedef struct _Efl_Loop_Consumer_Promise Efl_Loop_Consumer_Promise;
> > +struct _Efl_Loop_Consumer_Promise
> > +{
> > + EflLoopConsumerPromiseCancel func;
> > + Eina_Free_Cb free;
> > + void *data;
> > + Eo *obj;
> > +};
> > +
> > +static void
> > +_cancel_free(void *data)
> > +{
> > + Efl_Loop_Consumer_Promise *lcp = data;
> > +
> > + if (lcp->free) lcp->free(lcp->data);
> > + efl_unref(lcp->obj);
> > + free(lcp);
> > +}
> > +
> > +static void
> > +_cancel_triggered(void *data, const Eina_Promise *p)
> > +{
> > + Efl_Loop_Consumer_Promise *lcp = data;
> > +
> > + if (lcp->func) lcp->func(lcp->data, lcp->obj, p);
> > +}
> > +
> > +static void
> >
