@@ -1116,11 +1116,6 @@ fire_attach_profiler_events (MonoNativeThreadId tid)
1116
1116
}
1117
1117
1118
1118
1119
- #ifdef MONO_EMSCRIPTEN_KEEPALIVE_WORKAROUND_HACK
1120
- /* See ves_icall_System_Threading_WebWorkerEventLoop_KeepalivePopInternal */
1121
- __thread uint mono_emscripten_keepalive_hack_count ;
1122
- #endif
1123
-
1124
1119
static guint32 WINAPI
1125
1120
start_wrapper_internal (StartInfo * start_info , gsize * stack_ptr )
1126
1121
{
@@ -4979,34 +4974,13 @@ ves_icall_System_Threading_LowLevelLifoSemaphore_ReleaseInternal (gpointer sem_p
4979
4974
void
4980
4975
ves_icall_System_Threading_WebWorkerEventLoop_KeepalivePushInternal (void )
4981
4976
{
4982
- #ifdef MONO_EMSCRIPTEN_KEEPALIVE_WORKAROUND_HACK
4983
- mono_emscripten_keepalive_hack_count ++ ;
4984
- #endif
4985
4977
emscripten_runtime_keepalive_push ();
4986
4978
}
4987
4979
4988
4980
void
4989
4981
ves_icall_System_Threading_WebWorkerEventLoop_KeepalivePopInternal (void )
4990
4982
{
4991
4983
emscripten_runtime_keepalive_pop ();
4992
- #ifdef MONO_EMSCRIPTEN_KEEPALIVE_WORKAROUND_HACK
4993
- /* This is a BAD IDEA:
4994
- *
4995
- * 1. We don't know if there were non-mono callers of emscripten_runtime_keepalive_push. We
4996
- * could be dropping a thread that was meant to stay alive.
4997
- *
4998
- * 2. mono_thread_exit while we have managed frames on the stack means we might leak
4999
- * resource since finally clauses didn't run. Also the mono interpreter doesn't really get
5000
- * a chance to clean up.
5001
- *
5002
- *
5003
- */
5004
- mono_emscripten_keepalive_hack_count -- ;
5005
- if (!mono_emscripten_keepalive_hack_count ) {
5006
- g_warning ("thread %p mono keepalive count is zero, detaching\n" , (void * )(intptr_t )pthread_self ());
5007
- mono_thread_exit ();
5008
- }
5009
- #endif
5010
4984
}
5011
4985
5012
4986
extern int mono_wasm_eventloop_has_unsettled_interop_promises (void );
0 commit comments