# Compiler work priorities

**URL:** <https://discourse.julialang.org/t/compiler-work-priorities/17623>\
**Category:** Internals & Design\
**Created:** [November 16, 2018, 10:14pm UTC](https://discourse.julialang.org/t/compiler-work-priorities/17623 "2018-11-16T22:14:46Z")\
**Posts on this page:** 1\
**Showing post:** 11

<div class="post-metadata">

**Author:** ![tkf](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tkf/32/17635_2.png) [@tkf](https://discourse.julialang.org/u/tkf)\
**Post date:** [November 18, 2018, 2:44pm UTC](https://discourse.julialang.org/t/compiler-work-priorities/17623/11 "2018-11-18T14:44:10Z")

</div>

> [@tim.holy](#):
>
> It may be part of the compiler-time latency “caching more things” and “PackageCompiler,” but I would agree that “getting Julia to the point where it generates great `.so` files that can be used by other languages” would likely have a positive impact on Julia adoption.

I can’t agree more. But another obstacle for this goal is that Julia runtime takes over [all signal handlings](https://github.com/JuliaPy/pyjulia/issues/211) (though I guess this is not what compiler does so I guess this is a bit off topic). It especially is problematic for SIGINT handler since you can’t respond to ctrl-c in your program as soon as you initialize Julia runtime. It would be nice to have an API to initialize Julia runtime without taking over all signal handlings, or at least not SIGINT (something like CPython’s [`Py_InitializeEx(0)`](https://docs.python.org/3/c-api/init.html#c.Py_InitializeEx)).

---

_[View the full topic](https://discourse.julialang.org/t/compiler-work-priorities/17623)._