Nomnom Cookie posted:

is logback formatting synchronized, i don't think it is. anyway what the async appender does is shove log events onto a queue for the writer thread to consume. pretty much what you're describing except that its not the default

Shaggar posted:

yeah I was gonna say I don't see any reason you couldn't use slf4j/logback and just write you're own batching appender. formatting is done during appending so theoretically you could have an appender that just sends raw, unformatted events on thru to a batching process (at its outer queue) which internally handles formatting and actual writing of logs based on internal settings about what to do when getting full or w/e.

ex: in process A you do logger.info("its pizza time") and the underlying logger fires that event into the queue of process LOGGER with no formatting done. Then that process is responsible for handling its outer queue and making sure each event is formatted and spat out where it belongs. Even though the submit to the LOGGER process would be synchronized, if I understand u correctly that's what you're already doing. the heavy tasks that might result in pauses will be done by the LOGGER process which is what you want plus you move formatting there as well, so you're normal processes are faster.

Shaggar posted:

When people talk about processes in earlang do they actually mean threads or do they really mean separate processes?

MononcQc posted:

Yeah I was looking at the sequence diagram from the architecture docs, and saw the loop square and thought 'I guess this is the synchronous poo poo'. Reading this: http://logback.qos.ch/manual/appenders.html makes it look like there's filtering done as part of that call and no explicit formatting.

However, looking at specific appenders provided such as OutputStreamAppender reveals that there's a chain of calls that is append() > subAppend() > writeOut > this.encoder.doEncode(event);, which in turns defers to whatever encoder you have defined.

At this point I'm not a java dev and I'm not used to reading it, but it looks like by default it does do all its formatting (layout?) and whatnot as part of the synchronized area of the code, although you would be free to reimplement that behaviour to not do it.

MononcQc posted:

fyi this is pretty much what I ended up implementing except not in Java and formatting done at the call site instead because I just can and it's better to do that than overload a single process to be doing a lot of lovely string formatting in our case.

I'm trying to retrofit that in the standard logging library that does proper handling of all the filtering, log event level management, tracing support, etc. in a way that will be non-painful and optional to people who require it.


You get one native thread per core. Each thread runs a scheduler and a run queue. They do they equivalent of green threads, but with processes (nothing shared), and they're preemptively scheduled. There's load-balancing and work-stealing, process immigration and whatnot that's automated to make sure you get a good distribution over all CPUs done for you automatically, but you can also tell the VM to respect CPU affinity as much as possible if you want.

Shaggar posted:

so processes are green threads that cant share memory/objects but can communicate thru defined message endpoints?

Shaggar posted:

my autism is triggered when you refer to a process exiting cause I think u mean ur runtime and not just a thread.

MononcQc posted:

more or less yes. that's the gist of it. poo poo's optimized for that so starting a new process is ~300 words in memory and takes ~10µs, message passing is equally fast, and you get to be able to do introspection on pretty much everything you want for each process natively, but otherwise that's pretty much that.

Shaggar posted:

we do that in other languages we just call them by their correct name (threads)

Cocoa Crispies posted:

when you're banging out a message to an erlang on another computer does the runtime put it in a local queue so it doesn't take forever?

Shaggar posted:

we do that in other languages we just call them by their correct name (threads)

Shaggar posted:

90% of logback users are gonna use stuff as is and not care about the implementation cause it wont affect them.
another 9% will decide they need to write their own appender because they have a special snowflake destination for the logs and they will just extend something like outputstreamappender cause they don't need/want/care to have to change how encoding/formatting works
then the 1% of folks like you can just reimplement it in a way that suits their super custom needs, but still fits into the appender api

its a really good library.

MononcQc posted:

Shaggar posted:

my autism is triggered when you refer to a process exiting cause I think u mean ur runtime and not just a thread.

MononcQc posted:

I'm gonna go high-five go programmers for their goroutines

MononcQc posted:

yeah the big improvements of Erjang were over numerical code (mostly floating point ops) and message passing (no copying), but that meant Erjang had to forego the soft realtime constraints that BEAM Erlang gives you.

The project got a little kick lately because they're making it work with Elixir to see if there's more interest from what I understand

Otto Skorzeny posted:

Baller sig btw

gucci void main posted:

One language to rule them all.

gucci void main posted:

I'm putting my faith in Ruby. It might take 10 years, but eventually the performance will resemble C's. It's basically a compile-to-C language right now as it is. There's just a whole bunch of inefficiencies in the implementation. Once they get ironed out, we'll finally be able to have our cake and eat it too. One language to rule them all.

unixbeard posted:

here are some posts about some c++ stuff i had never bothered to try understand http://cachelatency.com/ they seem reasonable

hackbunny posted:

Pretty basic stuff, some things he doesn't seem to understand fully though, like auto, or maybe it's just the condescending tone of "some of you other programmers may need training wheels for your code, but not this guy " ("auto" is not just for lazy fuckers, dummo, it's a necessity to support some of the new language features). Or, i may just be biased against idiots who use the term "syntactic sugar"

unixbeard posted:

i would like to better understand the preconditions for use. it seems to me the new features were added for a reason like "i am doing x and y, and now I need to do z, which i cant due to some intractable problem or only through some super hackish solution, but new feature is designed to resolve it cleanly"

hackbunny posted:

The rationale behind the new RNG API is pretty well explained by that blog post. Ill add that no other language that I know of has such a fancypants built-in RNG as C++11

gucci void main posted:

I'm putting my faith in Ruby. It might take 10 years, but eventually the performance will resemble C's. It's basically a compile-to-C language right now as it is. There's just a whole bunch of inefficiencies in the implementation. Once they get ironed out, we'll finally be able to have our cake and eat it too. One language to rule them all.

Notorious b.s.d. posted:

nope

hackbunny posted:

The rationale behind the new RNG API is pretty well explained by that blog post. Ill add that no other language that I know of has such a fancypants built-in RNG as C++11

Nomnom Cookie posted:

java.security.SecureRandom biyatch