Hi Geoff, all, So are the changes in this "alternate interface" constrained to making it non-blocking, or are there other feature/semantic changes as well? I think having a non-blocking version of our API makes good sense, although it would be nice to discuss as a group and come to agreement on what that should look like, since our goal is to share an API. Perhaps I'm out of the loop, and this has been discussed in detail without me. Regards, Rob On Jul 25, 2013, at 9:24 AM, Danielson, Geoffrey Charles wrote:

Clients use it. Instead of the storage calls being blocking (as in asg.h), they return a context that can either be polled over the course of the operation or used in a (client-supplied) callback. Sirocco has an alternate interface that has diverged quite a bit from the ASG interface (though we do support both!).

From: Phil Carns <[email protected]> Date: Thursday, July 25, 2013 7:50 AM To: "[email protected]" <[email protected]> Subject: [EXTERNAL] Re: [ASG] 2013-07-22 Sandia Status Update

On 07/22/2013 03:29 PM, Danielson, Geoffrey Charles wrote:

...

All,

We continue working on our milestone front. To that end we: • Implemented a post and poll interface to the storage server (to be superseded shortly by a post and callback interface)

Thanks Geoff. Could you elaborate a little bit on what this interface is (i.e. who uses it)?

-Phil

...

• Improved our client locking scheme Regards, Geoff Danielson HP ES [email protected] [email protected] Desk: 505-844-8109 Cell: 505-263-0751

_______________________________________________ ASG mailing list

[email protected]https://lists.mcs.anl.gov/mailman/listinfo/asg

_______________________________________________ ASG mailing list [email protected] https://lists.mcs.anl.gov/mailman/listinfo/asg

Thanks. -- Rob On Jul 25, 2013, at 9:48 AM, Danielson, Geoffrey Charles wrote:

It also does scatter-gather (within a fork) operations on read and write.

It was presented during our status update presentation on 1 July, though I don't believe the non-blocking part of it was conceived at that point.

On 7/25/13 8:36 AM, "Rob Ross" <[email protected]> wrote:

...

Hi Geoff, all,

So are the changes in this "alternate interface" constrained to making it non-blocking, or are there other feature/semantic changes as well?

I think having a non-blocking version of our API makes good sense, although it would be nice to discuss as a group and come to agreement on what that should look like, since our goal is to share an API. Perhaps I'm out of the loop, and this has been discussed in detail without me.

Regards,

Rob

On Jul 25, 2013, at 9:24 AM, Danielson, Geoffrey Charles wrote:

...

Clients use it. Instead of the storage calls being blocking (as in asg.h), they return a context that can either be polled over the course of the operation or used in a (client-supplied) callback. Sirocco has an alternate interface that has diverged quite a bit from the ASG interface (though we do support both!).

From: Phil Carns <[email protected]> Date: Thursday, July 25, 2013 7:50 AM To: "[email protected]" <[email protected]> Subject: [EXTERNAL] Re: [ASG] 2013-07-22 Sandia Status Update

On 07/22/2013 03:29 PM, Danielson, Geoffrey Charles wrote:

...

All,

We continue working on our milestone front. To that end we: € Implemented a post and poll interface to the storage server (to be superseded shortly by a post and callback interface)

Thanks Geoff. Could you elaborate a little bit on what this interface is (i.e. who uses it)?

-Phil

...

€ Improved our client locking scheme Regards, Geoff Danielson HP ES [email protected] [email protected] Desk: 505-844-8109 Cell: 505-263-0751

_______________________________________________ ASG mailing list

[email protected]https://lists.mcs.anl.gov/mailman/listinfo/asg

_______________________________________________ ASG mailing list [email protected] https://lists.mcs.anl.gov/mailman/listinfo/asg

All, Attached, find a copy of sirocco.h The calls do not become non-blocking by virtue of being in a transaction. They become non-blocking by virtue of not blocking the caller until the remote storage server finishes its operation. Using this API, there are three paths the caller can follow. Non-blocking - the read and write functions return a context that: 1) if supplied with a callback, will fire the callback when the operation completes (when the storage server returns a status and/or return values). 2) if not supplied with a callback, can be polled by the caller (using sir_wait), until such time as the storage server returns a status and/or return values (when sir_wait will return 0 instead of -1 and setting errno). Blocking: 3) the blocking_read/blocking_write will block the caller until the operation completes (using pthread signals). Hope this helps! -G On 7/26/13 2:34 PM, "Dries Kimpe" <[email protected]> wrote:

* Danielson, Geoffrey Charles <[email protected]> [2013-07-25 14:48:32]:

...

It also does scatter-gather (within a fork) operations on read and write.

...

It was presented during our status update presentation on 1 July, though I don't believe the non-blocking part of it was conceived at that point.

There's not that much detail in the presentation. Did you mean that the interface becomes non-blocking by moving the calls inside of a transaction? (on which one can wait?)

It would be nice if you could send the API to the list, or provide some more details otherwise.

Thanks, Dries

Sure thing: These all assume that you've initialized your arguments as defined in the sirocco structures. Callback (assumes a function named "callback" is defined by the caller, which will take the sir_rv and a user-defined argument "arg_to_callback"): sir_rv rv = sir_write(sirocco_context, peer, key_node, input_args, input_args_count, buffer, output_args, output_args_count, &arg_to_callback, callback); // do other things as necessary, until the callback fires Post and Poll: sir_rv rv = sir_write(sirocco_context, peer, key_node, input_args, input_args_count, buffer, output_args, output_args_count, NULL, NULL); while(sir_wait(rv)) { Sleep(2); //or possibly go do some other necessary thing instead of just sleeping... } Blocking: ssize_t rv = sir_blocking_write(sirocco_context, peer, key_node, input_args, input_args_count, buffer, output_args, output_args_count); -G On 7/26/13 2:52 PM, "Dries Kimpe" <[email protected]> wrote:

* Danielson, Geoffrey Charles <[email protected]> [2013-07-26 20:44:30]:

...

Attached, find a copy of sirocco.h

...

The calls do not become non-blocking by virtue of being in a transaction. They become non-blocking by virtue of not blocking the caller until the remote storage server finishes its operation.

...

Using this API, there are three paths the caller can follow.

...

Non-blocking - the read and write functions return a context that: 1) if supplied with a callback, will fire the callback when the operation completes (when the storage server returns a status and/or return values).

...

2) if not supplied with a callback, can be polled by the caller (using sir_wait), until such time as the storage server returns a status and/or return values (when sir_wait will return 0 instead of -1 and setting errno).

...

Blocking: 3) the blocking_read/blocking_write will block the caller until the operation completes (using pthread signals).

...

Hope this helps!

Thanks! It does.

To make sure I understand correctly, could you give some code examples (pseudocode is fine) showing how these modes are used?

This will clarify things about context reuse, etc.

THanks, Dries

At this point, it's the user's responsibility, as the ssize_t return value is contained within the sir_rv context. Had we added a ssize_t * to the arguments to sir_write and sir_read, both sir_ctxrtn and sir_retire could be done away with, but that's an API revision for another day. On 7/30/13 5:36 PM, "Dries Kimpe" <[email protected]> wrote:

Is the user responsible for calling sir_retire() or is it done automatically the moment sir_wait() returns false?

Thanks, Dries