On Fri, Jun 24, 2016 at 11:02 PM, Antti Kantee <[email protected]> wrote: > > Well, it probably won't take too many minutes to at least identify the > problem. >
My gut feeling is that this has something to do with memory allocation (based on my initial attempt to port Erlang on Rumprun) and I wonder what will happen if mmap is called with memory allocation larger than the system available memory in Rumprun? > But I don't want to distract you from the tracing efforts ;) > I somehow want to find an excuse to take the longer path, hopefully adding more value in general. Having said that I'd probably envisage it in multiple phases to get something out sooner than later. > I wonder what the thread-specific limitations of barectf would mean in > context of Rumprun. Please keep us posted of discoveries. > While using barectf in my projects I wrote my handler code which used thread local context to buffer the events and then dump to a file specific to that thread. In general I dont like to lock unless absolutely necessary. I dont think code generated by barectf care about threads and locking, which is nice because then the client can implement whatever makes sense. Note that the barectf project is licensed under MIT while rumprun and rumpkernel are under 2-clause BSD. I believe MIT licensed software can be used in BSD, but then I am not a lawyer :) -Neeraj
