Re: Implementing a cancelable task

[Alessio Vanni]

Christian Grothoff <grothoff@gnunet.org> writes:

> Hi Alessio,
>
> I would like to help, but I doubt I fully understand your question! From
> what I get, you want to do some action based on another peer sending you
> a reply. So associating a unique number with the request that the other
> peer is to include in the reply is indeed the right way to do this.
> Sure, you cannot trust that the other peer does this correctly, but here
> you should simply check that the unique number is in the list of
> (active) unique numbers you shared with that peer. That way, you should
> be able to limit what 'bad things' the other peer can do to sending a
> reply to the wrong request -- which you cannot really prevent ever.

Sorry, I guess I wasn't totally clear.
I hope the following is clearer.

Let's say I have a function with this signature:

struct MyAsyncTask *
myservice_do_something(MyServiceHandle *handle, ...)

(the arguments are not important) which starts an async operation by
communicating with a service.  This operation can take any amount of
time, so it can either be instantaneous or might take a while due to
network latency or some other factor.

The return value is a structure that allows the user to call this other
function:

void
myservice_cancel(struct MyAsyncTask *task)

which stops the requested operation from being completed.

What it means to be stopped doesn't really matter: it might be actually
avoiding adding a message to the message queue or it might simply be not
calling a specific callback.  Anyway, the result after calling the
function is that the task is canceled and whatever was registered to
operate on it is not executed.

The problem I'm facing is that due to the presence of CADET, I don't
have an immediate way to associate a certain task with a certain reply,
as CADET is another async operation.

If really the only way (or the more correct) is to have the ID in the
message sent to the remote peer then I supposed I'll do it, but I
thought I'd first ask people with more expertise, especially since I'd
like to have it work similarily to what GNUnet offers in its services'
APIs (e.g. `GNUNET_GNS_lookup_cancel'.)

> Anyway, if this doesn't help -- as it was already pointed out -- you may
> also have better luck on the gnunet-developers list for this.

If things are still unclear I'll move there.
Just tell me if I have to clarify some things! I'm the one asking for
help after all...

> Given that I am not sure I fully understand the question, an even better
> forum might be the ~monthly Mumble (next on August 8th at 8pm CEST) on
> gnunet.org, as a more interactive medium may help people understand your
> problem in the first place ;-).

Unfortunately the time for this month is a bit of a problem, but I'll
keep it in mind!

Thanks,
A.V.