{"action":"created","issue":{"url":"https://api.github.com/repos/vert-x3/vertx-lang-kotlin/issues/54","repository_url":"https://api.github.com/repos/vert-x3/vertx-lang-kotlin","labels_url":"https://api.github.com/repos/vert-x3/vertx-lang-kotlin/issues/54/labels{/name}","comments_url":"https://api.github.com/repos/vert-x3/vertx-lang-kotlin/issues/54/comments","events_url":"https://api.github.com/repos/vert-x3/vertx-lang-kotlin/issues/54/events","html_url":"https://github.com/vert-x3/vertx-lang-kotlin/issues/54","id":312329188,"node_id":"MDU6SXNzdWUzMTIzMjkxODg=","number":54,"title":"Provide an awaitBlocking function for specific context","user":{"login":"oripwk","id":5026382,"node_id":"MDQ6VXNlcjUwMjYzODI=","avatar_url":"https://avatars0.githubusercontent.com/u/5026382?v=4","gravatar_id":"","url":"https://api.github.com/users/oripwk","html_url":"https://github.com/oripwk","followers_url":"https://api.github.com/users/oripwk/followers","following_url":"https://api.github.com/users/oripwk/following{/other_user}","gists_url":"https://api.github.com/users/oripwk/gists{/gist_id}","starred_url":"https://api.github.com/users/oripwk/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/oripwk/subscriptions","organizations_url":"https://api.github.com/users/oripwk/orgs","repos_url":"https://api.github.com/users/oripwk/repos","events_url":"https://api.github.com/users/oripwk/events{/privacy}","received_events_url":"https://api.github.com/users/oripwk/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":2,"created_at":"2018-04-08T18:44:42Z","updated_at":"2018-10-29T08:15:16Z","closed_at":null,"author_association":"NONE","body":"In issue #42 a new function was added for running blocking code on the worker pool and as a coroutine.\r\n\r\nHowever, the function calls `executeBlocking` internally using `Vertx.currentContext()`. This is problematic for the following reasons:\r\n1. It make this function less modular and reusable, since it depends on global state\r\n1. It does not allow control for the developer on which context to run the code\r\n1. It causes problems in testing since it will always return null because the test code does not run on the event loop.\r\n\r\nOn the other hand, `executeBlocking` _does_ allow control on which context to run. `awaitBlocking` is somewhat a flavor of `executeBlocking` which works without the need to provide a future, so there's no reason it won't mirror `executeBlocking` functionality."},"comment":{"url":"https://api.github.com/repos/vert-x3/vertx-lang-kotlin/issues/comments/433822376","html_url":"https://github.com/vert-x3/vertx-lang-kotlin/issues/54#issuecomment-433822376","issue_url":"https://api.github.com/repos/vert-x3/vertx-lang-kotlin/issues/54","id":433822376,"node_id":"MDEyOklzc3VlQ29tbWVudDQzMzgyMjM3Ng==","user":{"login":"oripwk","id":5026382,"node_id":"MDQ6VXNlcjUwMjYzODI=","avatar_url":"https://avatars0.githubusercontent.com/u/5026382?v=4","gravatar_id":"","url":"https://api.github.com/users/oripwk","html_url":"https://github.com/oripwk","followers_url":"https://api.github.com/users/oripwk/followers","following_url":"https://api.github.com/users/oripwk/following{/other_user}","gists_url":"https://api.github.com/users/oripwk/gists{/gist_id}","starred_url":"https://api.github.com/users/oripwk/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/oripwk/subscriptions","organizations_url":"https://api.github.com/users/oripwk/orgs","repos_url":"https://api.github.com/users/oripwk/repos","events_url":"https://api.github.com/users/oripwk/events{/privacy}","received_events_url":"https://api.github.com/users/oripwk/received_events","type":"User","site_admin":false},"created_at":"2018-10-29T08:15:16Z","updated_at":"2018-10-29T08:15:16Z","author_association":"NONE","body":"@lfmunoz I do not agree that it implies the code is not structured correctly.\r\n* A code that uses Vert.x's default `awaitBlocking` method is not testable outside a running Vert.x app since it requires the test code to be coupled with Vert.x.\r\n* Generally speaking (practices-wise), anything that depends on global state is not modular and makes everything harder.\r\n* `executeBlocking` (unlike `awaitBlocking`) has a flavor where you call it on the `vertx` object itself: `vertx.executeBlocking(…)`. Why not have the same thing with `awaitBlocking`?\r\n\r\n@vietj can you please advice?"}}
{"actor":{"display_login":"oripwk"}}