{"action":"closed","issue":{"url":"https://api.github.com/repos/libpd/libpd/issues/136","repository_url":"https://api.github.com/repos/libpd/libpd","labels_url":"https://api.github.com/repos/libpd/libpd/issues/136/labels{/name}","comments_url":"https://api.github.com/repos/libpd/libpd/issues/136/comments","events_url":"https://api.github.com/repos/libpd/libpd/issues/136/events","html_url":"https://github.com/libpd/libpd/issues/136","id":158584626,"number":136,"title":"move sys_microsleep(0) to another thread","user":{"login":"giuliomoro","id":4260604,"avatar_url":"https://avatars.githubusercontent.com/u/4260604?v=3","gravatar_id":"","url":"https://api.github.com/users/giuliomoro","html_url":"https://github.com/giuliomoro","followers_url":"https://api.github.com/users/giuliomoro/followers","following_url":"https://api.github.com/users/giuliomoro/following{/other_user}","gists_url":"https://api.github.com/users/giuliomoro/gists{/gist_id}","starred_url":"https://api.github.com/users/giuliomoro/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/giuliomoro/subscriptions","organizations_url":"https://api.github.com/users/giuliomoro/orgs","repos_url":"https://api.github.com/users/giuliomoro/repos","events_url":"https://api.github.com/users/giuliomoro/events{/privacy}","received_events_url":"https://api.github.com/users/giuliomoro/received_events","type":"User","site_admin":false},"labels":[],"state":"closed","locked":false,"assignee":null,"milestone":null,"comments":1,"created_at":"2016-06-06T00:56:53Z","updated_at":"2016-06-16T02:16:56Z","closed_at":"2016-06-16T02:16:56Z","body":"For my application, which uses xenomai, I have to move `libpd_sys_microsleep(0)` outside of `libpd_process_float`.\r\n\r\nWhile I will not use `[netsend]` and `[netreceive]` in my patches, I still want to be able to have file I/O (e.g.: `[soundfiler]`, `[readsf~]`), so I need the calls to `libpd_sys_microsleep(0)` to happen every so often in a non-time critical thread, managed by my application.\r\n\r\nIs there any known way to address thread-safety issues that come with this? Locking the audio thread is not an option."}}
{"actor":{"display_login":"giuliomoro"}}