reef-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Markus Weimer <mar...@weimo.de>
Subject Re: ITask and IDisposable
Date Mon, 09 Jul 2018 23:44:56 GMT
Replying, as Tyson had some issues with receiving the list today. -- Markus

On Mon, Jul 9, 2018 at 11:51 AM, Julia Wang (QIUHE) <
Qiuhe.Wang@microsoft.com.invalid> wrote:

> Regarding task Dispose vs Close, I believe the bottom line is we want to
> ensure the resource used in task is released in any cases as otherwise
> evaluator won't be clean if we want to reuse it in fault tolerant
> scenarios.
>
> In normal scenario, Close() will be called and we can dispose task in
> Close. What if in some scenarios task suddenly crashes and there is no
> chance for Close to be called? In Task dispose method, we usually always
> check only to release resources if it is not released yet, so overlap case
> is covered.
>
> If we can sure Close is always called in any failed/crash scenarios, we
> may not need to overlap, which I agree.
>
> Thanks,
> Julia
>
> -----Original Message-----
> From: Markus Weimer <markus@weimo.de>
> Sent: Monday, July 9, 2018 9:23 AM
> To: REEF Developers Mailinglist <dev@reef.apache.org>
> Subject: Re: ITask and IDisposable
>
> Good find! We'd need input from more .NET experienced devs here.
>
> That being said, the Java `Task` doesn't extends `AutoCloseable`, which
> would be the equivalent of `IDisposable`. Maybe the right call here is to
> remove the `IDisposable` from the interface? And add code that checks
> whether task indeed implements it and if so, follows the current behavior
> with a WARNING in the log?
>
> Markus
>
> On Sun, Jul 8, 2018 at 11:21 AM,  <tcondie.apache@gmail.com> wrote:
> > Now that I've been digging deeper into the existing REEF.Net
> > implementation, I have come across something that concerns me.
> > Presently, ITask implements IDisposable, which from my understand
> > should be the last call any C# object should receive i.e., the object
> > is effectively dead after its Dispose method is called. Unfortunately,
> this is presently violated in REEF.Net.
> > Specifically, when a task is explicitly closed by the driver, the C#
> > TaskRuntime will call the task's Dispose method. After which, the call
> > method (ideally) returns and the TaskRuntime subsequently calls the
> > stop handlers, which based on my implementation (and many other
> > existing
> > applications) calls the task object that was previously disposed.
> >
> >
> >
> > My question then is why are we having ITask implement IDisposable when
> > we have perfectly good event handlers for cleanup e.g., StopEvent? I'm
> > fine with keeping IDisosable as long as we ensure that Dispose is the
> > absolute last call ever made to an object that could belong to the
> application.
> > However, if there's no good reason for having Dispose over existing
> > handlers then perhaps we should remove it. In general, I also find it
> > confusing to have methods with overlapping semantics i.e., what should
> > I put into my stop handler vs. what should go into Dispose. they seem
> > to serve the same purpose.
> >
> >
> >
> > Bottom line, I do not know the right answer here but I do feel that we
> > should avoid calling any methods on an object that has had its Dispose
> > method already called. Presently, this is not the case in REEF.Net
> >
> >
> >
> > -Tyson
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message