I've been looking through the control flow for the monero daemon to understand it a little better and I'm trying to find the main event loop but keep getting lost in a sea of C++. I pinned it down to the run() function on line 1005 in p2p/net_node.inl but can't figure out where this leads to. Does anybody in here know where the main loop for the daemon/server lives? I see it calls out to a .run_server function but I don't know where that

goes either as it is the only reference I see to it in the codebase.

all of that is in the epee source

which is a PITA to read...

karce[m] I uses boost asio. Check "boosted_tcp_server<t_protocol_handler>::worker_thread()"

*It uses

from there it eventually goes back to net_node functions, like handle_handshake, on_connection_new and so on

Ok thanks that's more of what I was looking for. At least the main functions used to run the server and handle connections/signals, etc.

you can always debug break in one of these functions and check the call stack to see the full picture

That would probably be a lot better use of my time than going line by line, huh? haha

One more vote for using a good and interactive debugger. Just break and watch where you come from, like sech1 said.

It's great advice. I'll go and do that and see what I can find. I haven't debugged C++ in a while. I guess I'll use gdb but I think I'll have to compile it with debug enabled too.

rbrunner: I discovered that's a convenient way to recover the call stack when an exception is thrown under debug mode, very handy.

karce[m]: vscodium has worked great for me (gui for debugging is a must-have), here is how to get set up paste.debian.net/hidden/514ae606

Thanks I actually use vscodium for my main development already so this is super useful.

UkoeHB: I followed those instructions and it worked, with some modifications. Had to run make with debug of course. Also there were some lines of code that wouldn't compile for debug but would for release on v18.1.x in contrib/epee/include. But debugging is working now in vscodium.

great :)

karce[m] if there are lines that won't compile for you, would you mind opening a github issue or pull request so that can be fixed (if possible)?

I can. They only wouldn't compile in 'debug', just two lines and it is because of the -Werror=return-type flag. I'm not sure it isn't something due to my environment but after I changed the two source line it worked fine.

Reading epee and cryptonote protocol code is dense. Thanks for the help everyone. Now I sleep...

As much as the xmrig do a 1% default contribution embeded in the config (wih the possibility of changing it) ...won't the monero community accept such settings within the monerod ..so that this could add to the self sustaining development

selenze[m]: zero dev tax is a point of pride for monero

for the monero community and dev team *

well, allow me. but what about the problems that are real.

what if the comm can voluntary accept a necessary tax

for the good of everybody.

it is an important part of the 'social contract' that holds everything together, I imagine any fork introduced by the main dev team with a dev tax would destroy the project

or at least seriously split the community, to everyone's detriment

what if the comm can vote on that....situations change.....just like the Deb recently changed on their social contract.

I mean we can adjust the ratings...allocate certain time period....like what wikipedia does...or any arrangement.

this isn't a democracy, and we try to minimize shades of technocracy; an essential part of working on monero is respecting and promoting the core design goals - privacy, censorship resistance, protocol longevity, etc.; a dev tax would directly undermine the second two

anyway, I'm sure the guys over at #monero-community would happily talk to you about it more, it's a little off-topic for dev

I understand your concern and and am aware of the many discussion that have been through...but this is not like what the coin miners do...infact to the sustainability of the things you mentioned...and the very fact that monero is money ..it is indeed a self sustaining mechnism. Just we put all the control mechanism in the hands of the comm....how can this negate to its prinicples. I see no issue implementing a self sustaining economy. I

am only talking to the availability of funds in a transparent manner with all the accountability.

The most effective way to think about monero is to consider devs as custodians and the community as users. Neither group has the right to modify the core design goals or what monero 'is' - monero must be treated as an abstraction that stands apart from us.

Hopefully when I'm old I won't look back on these sentiments with disappointment after some future custodial failures...

but that abstraction is build and framed by us...we the people. How can this be entrenched...or I expect a good reason the way around this...apart from the CCS. Are you saying you are comfortable with the now and then pains of the CCS..especially for the ones that may be left hanging on the big projects.

I think if you want something that isn't monero, you shouldn't be looking at monero for answers :)

The short, technical answer is monero is in the class of digital currency projects that try to digitally instantiate something that looks and behaves like a physical system - e.g. like gold. Physical systems have rules that emerge from the fabric of reality - they are constant.