{"action":"created","issue":{"url":"https://api.github.com/repos/mono/mono/issues/2435","labels_url":"https://api.github.com/repos/mono/mono/issues/2435/labels{/name}","comments_url":"https://api.github.com/repos/mono/mono/issues/2435/comments","events_url":"https://api.github.com/repos/mono/mono/issues/2435/events","html_url":"https://github.com/mono/mono/pull/2435","id":126563524,"number":2435,"title":"Improve support for Xamarin platform extensions","user":{"login":"xmcclure","id":15091917,"avatar_url":"https://avatars.githubusercontent.com/u/15091917?v=3","gravatar_id":"","url":"https://api.github.com/users/xmcclure","html_url":"https://github.com/xmcclure","followers_url":"https://api.github.com/users/xmcclure/followers","following_url":"https://api.github.com/users/xmcclure/following{/other_user}","gists_url":"https://api.github.com/users/xmcclure/gists{/gist_id}","starred_url":"https://api.github.com/users/xmcclure/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/xmcclure/subscriptions","organizations_url":"https://api.github.com/users/xmcclure/orgs","repos_url":"https://api.github.com/users/xmcclure/repos","events_url":"https://api.github.com/users/xmcclure/events{/privacy}","received_events_url":"https://api.github.com/users/xmcclure/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":1,"created_at":"2016-01-14T02:23:59Z","updated_at":"2016-01-14T17:14:37Z","closed_at":null,"pull_request":{"url":"https://api.github.com/repos/mono/mono/pulls/2435","html_url":"https://github.com/mono/mono/pull/2435","diff_url":"https://github.com/mono/mono/pull/2435.diff","patch_url":"https://github.com/mono/mono/pull/2435.patch"},"body":"- Clean up platform-specific define structure in processes.c, and\r\n  support a MONO_FORCE_GENERIC_MODULE_LOADING to disable the\r\n  platform-specific options.\r\n- Do not use platform-specific win32 sgen when coop gc is on\r\n- Fix pervasive thing where debug prints were assuming native thread\r\n  ids can be cast directly to gpointer (they might be ints)\r\n- Move some type declarations out of threadpool-ms-io.c into a new\r\n  threadpool-ms-io-backend.h\r\n- Support a MONO_FORCE_EXTERN_THREADPOOL_BACKEND macro to support the\r\n  threadpool backend being a particular statically linked symbol.\r\n- Fix out of date comment on mono_jit_init_version\r\n- Make the ucontext support detection in mono-context.c based on\r\n  MONO_SIGNAL_USE_SIGACTION again (since we do not save contexts when\r\n  we are not using SIGACTION)— but mirror USE_SIGACTION into a new\r\n  MONO_SUPPORT_UCONTEXT flag in case we realize we need to use\r\n  contexts without signals later."},"comment":{"url":"https://api.github.com/repos/mono/mono/issues/comments/171709683","html_url":"https://github.com/mono/mono/pull/2435#issuecomment-171709683","issue_url":"https://api.github.com/repos/mono/mono/issues/2435","id":171709683,"user":{"login":"xmcclure","id":15091917,"avatar_url":"https://avatars.githubusercontent.com/u/15091917?v=3","gravatar_id":"","url":"https://api.github.com/users/xmcclure","html_url":"https://github.com/xmcclure","followers_url":"https://api.github.com/users/xmcclure/followers","following_url":"https://api.github.com/users/xmcclure/following{/other_user}","gists_url":"https://api.github.com/users/xmcclure/gists{/gist_id}","starred_url":"https://api.github.com/users/xmcclure/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/xmcclure/subscriptions","organizations_url":"https://api.github.com/users/xmcclure/orgs","repos_url":"https://api.github.com/users/xmcclure/repos","events_url":"https://api.github.com/users/xmcclure/events{/privacy}","received_events_url":"https://api.github.com/users/xmcclure/received_events","type":"User","site_admin":false},"created_at":"2016-01-14T17:14:37Z","updated_at":"2016-01-14T17:14:37Z","body":"Comments refer to both this and https://github.com/mono/mono/pull/2435\r\n\r\nContinuing a discussion with @Kumpera:\r\n\r\n> What's the reason for MONO_FORCE_GENERIC_MODULE_LOADING?\r\n\r\nA source of difficulty in this PR is that 6-months-ago master did not support FreeBSD, and current master does support FreeBSD. In effect, six months ago we were using `__FreeBSD__` as a proxy for Orbis.\r\n\r\n`processes.c` has a series of platform-specific loaders and a generic loader. In current master, `processes.c` will detect FreeBSD when compiling for Orbis and attempt to use the BSD loader, which depends on dl.h, which the PS4 does not have. MONO_FORCE_GENERIC_MODULE_LOADING suppresses use of any platform-specific loader.\r\n\r\nAnother option would be to add a HAVE_DL_H to autoconf and only use the BSD loader if DL_H is present, but this approach is more generic.\r\n\r\n> And on the threadpool-io, I don't like \r\nMONO_FORCE_EXTERN_THREADPOOL_BACKEND either. It's a magic variable that\r\ncomes from nowhere.\r\n\r\nI don’t think I’d say it comes from nowhere— it comes from config.h, and if it’s not in config.h then the code is not used. However, it’s definitely true the code is not pretty.\r\n\r\nWithout using the MONO_FORCE_EXTERN_THREADPOOL_BACKEND trick though we will still need some way to tell threadpool “use this backend” defined in tpool-orbis.c without explicitly calling out Orbis or including tpool-orbis.h in threadpool-ms.c. How would you recommend doing this?\r\n\r\n> Besides that, have you tested it? IIRC I could not use poll in the first place and this is why I had to write that new backend. If poll now works, no point in having that.\r\n\r\nI have not tested my new orbis threadpool implementation. What do you mean that “poll” did not work? The old and new tpool-orbis definitions seem about the same, they are both based on sceNetEpollWait.\r\n\r\nI think we might still need a separate orbis backend because the sceNetEpoll interface seems to have some minor subtle differences with normal epoll.\r\n\r\nFrom mono PR discussion:\r\n\r\n> [USE_UCONTEXT] change is wrong, it introduces an extra define for no good reason. A better fix is the following: * remove MONO_SIGNAL_USE_SIGACTION * check for HAVE_UCONTEXT_H instead.\r\n\r\nAs discussed in chat, I investigated this solution this morning and discovered that HAVE_UCONTEXT_H is not necessarily true. Apparently ucontext.h has been deprecated because `getcontext`/`swapcontext` were deprecated in POSIX in favor of pthreads, and ucontext.h is no longer used on OS X for us, because autoconf will balk at the deprecation warning unless we specifically tell it not to. Without ucontext.h `ucontext_t` is instead supplied by the sigaction headers in some manner which does not seem to be predictable across platforms.\r\n\r\nThe correct switch still seems to be MONO_SIGNAL_USE_SIGACTION. I am introducing the additional level of indirection on top of that based on a request from Zoltan."}}