[LLVMdev] Should LLVM JIT default to lazy or non-lazy?

[Cornelius]

On 10/28/2009 08:59 PM, Evan Cheng wrote:
>
> On Oct 28, 2009, at 12:41 PM, Chandler Carruth wrote:
>
>> On Wed, Oct 28, 2009 at 12:21 PM, Evan Cheng<evan.cheng at apple.com>  wrote:
>>> On Oct 28, 2009, at 10:07 AM, Chandler Carruth wrote:
>>>>  From where I sit, this boils down to a very simple question (modulo
>>>> Chris's point): Either choice will surprise some users. Which surprise
>>>> is worse? Personally, I'd always prefer correct but slow behavior by
>>>> default, and explicitly enabling dangerous (but in some cases fast)
>>>> behavior.
>>>
>>> The behavior is only dangerous because people are using it in new and different ways.
>>
>> The fact that an interface, when used in new ways, exposes bugs this
>> severe and subtle indicates that it is a poor interface. Your argument
>> doesn't lend much weight, because the same can be said of computed
>> goto, the fork() system call, etc. Surviving new and different uses
>> *is* the purpose of a good interface.
>
> And your point is? We are talking about changing the default. That fixes the interface?
>
> I'd like to see some concrete proposal rather than flipping default behaviors. That does actually fix the problem. That just hides the problem. There won't be a consensus since we are lots of users with different needs. LLVM community has always let people who are doing to work make design decisions. Let's stick with that policy. Whoever is signed on to tackle the thread safety issue can decide what to do.
>
> Evan

Hi,
where's the problem from keeping the default like it is, sticking in an 
assert which triggers when the JIT is initialized with lazy compilation 
and multithreading active?
Then you could add a paragraph to the release notes, telling everyone 
that the Lazy JIT is not threadsafe, and be fine with it?
If this goes with an API change to an enum param or not, who cares?
Cornelius