[ 
https://issues.apache.org/jira/browse/TINKERPOP-1490?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15632124#comment-15632124
 ] 

ASF GitHub Bot commented on TINKERPOP-1490:
-------------------------------------------

Github user jorgebay commented on the issue:

    https://github.com/apache/tinkerpop/pull/478
  
    > What makes `toListAsync()` more "fully async" compared to 
`promise(traversal::toList)`? Internally, from a Java perspective anyway, 
`toListAsync()` does the same thing, doesn't it?
    
    By fully async I meant asynchronous execution that doesn't block in any 
call and doesn't require a threadpool. All the way down, it would be based on 
futures / async operations. In java, it would mean no 
`CompletableFuture::get()` calls.
    That translates into supporting higher levels of concurrency as there is no 
threadpool limiting the amount of calls in parallel.
    
    For TinkerPop, it would require asynchronous strategies as currently the 
blocking calls are made in the `apply()` method. I've suggested an 
`applyAsync()` method for an async strategy interface that returns a 
`CompletableFuture`.
    
    For other technologies, the same logic applies as we shouldn't care about 
the underlying framework / network library (Python tornado / libuv / ...) or 
thread pools.
    For C#, it would be `Task` all the way down; for Python it could be async 
generators or futures all the way down; for Javascript, Promise or async 
callbacks; ...


> Provider a Future based Traversal.async(Function<Traversal,V>) terminal step
> ----------------------------------------------------------------------------
>
>                 Key: TINKERPOP-1490
>                 URL: https://issues.apache.org/jira/browse/TINKERPOP-1490
>             Project: TinkerPop
>          Issue Type: Improvement
>          Components: language-variant, process
>    Affects Versions: 3.2.2
>            Reporter: Marko A. Rodriguez
>
> [~mbroecheler] had the idea of adding a {{Traversal.async()}} method. This is 
> important for not only avoiding thread locking on a query in Gremlin, but 
> also, it will allow single threaded language variants like Gremlin-JavaScript 
> to use callbacks for processing query results.
> {code}
> Future<List<String>> result = 
> g.V().out().values("name").async(Traversal::toList)
> {code}
> {code}
> Future<List<String>> result = g.V().out().name.async{it.toList()}
> {code}
> {code}
> g.V().out().values('name').async((err,names) => {
>   // I don't know JavaScript, but ...
>   return list(names);
> }) 
> {code}
> ...



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to