search

ECP-VeloC / AXL

Asynchronous Transfer Library
MIT License
2 stars 8 forks source link

Should we remove the synchronous option? #37

Closed gonsie closed 5 years ago

gonsie commented 5 years ago

Synchronous doesn’t make sense for Asynchronous Xfer.

Also, a synchronous transfer behaves differently as the user does not need to call wait.

Or, maybe we should just set the pthreads option to the default.

tonyhutter commented 5 years ago

I'm in favour of removing the sync code and replacing it with "pthreads using 1 thread". Note that the behaviour will be slightly different, since pthread will spawn one child thread to do the transfer, while sync uses the caller's thread.

adammoody commented 5 years ago

I'd recommend keeping the sync version in there, unless it's causing problems. It's useful as a fallback when all else fails.

I believe the library is written so that the caller still has to call all of the routines in the same sequence regardless of the transfer mode, or at least that was the intent:

Create, Add, Dispatch, Wait, Free

The reasoning here is so the caller doesn't have to keep track of the transfer type once it has been created.

I think the only confusing aspect is that it's a synchronous mode in a library that has the name asynchronous, but if that's a concern we could rename the library to just "file transfer library".

adammoody commented 5 years ago

I am in favor of dropping the forked process async_daemon method, though. It does work, but it takes some hand-holding as written. It would need to be fixed. However, the pthread version will be a better implementation of what it's trying to accomplish.

bnicolae commented 5 years ago

All, just as a reminder: VeloC has its own async strategy and needs the sync mode. Without the sync mode, AXL will spawn lots of threads unnecessarily (especially since VeloC will invoke a lot of parallel AXL instances).

gonsie commented 5 years ago

Thank you all for the comments. The general consensus is to leave in sync mode.