Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

What's the proper way to start wired? #42

Closed
0323pin opened this issue Dec 20, 2021 · 3 comments
Closed

What's the proper way to start wired? #42

0323pin opened this issue Dec 20, 2021 · 3 comments

Comments

@0323pin
Copy link
Contributor

0323pin commented Dec 20, 2021

Hi,
Not so much of an issue, more like a general question.
After packaging wired-notify for NetBSD yesterday, I'm taking it for a spin.

I've added wired & to my LeftWM start-up file and it's working as it should using the default wired.ron for now.
But, I wonder if this is the correct way to do it, since the following shows-up in top

2021-12-20-scrot

As you can see there're several instances running, each using a chuck of RAM. Should I start it as I do with picom, i.e. using something like

if [ -x "$(command -v picom)" ]; then
  picom --config $SCRIPTPATH/picom.conf &> /dev/null &
fi

Thanks!

@Toqozz
Copy link
Owner

Toqozz commented Dec 20, 2021

The proper way to start it is with wired &, like you've done. There are some community efforts for systemd services (#34) but I haven't really made them part of the program yet.

I'm slightly puzzled by your top, but can't look into it on my machine right now, will do tomorrow.

There are a few things though which could cause multiple processes like you see. On Wired master we're polling DBus in a separate thread to sort of work around an issue (diwic/dbus-rs#364), which explains one of them, and then there's the main thread and I believe Winit might spawn a new thread for each window as well.

In regards to ram usage, I should probably look into it. I haven't been excessively careful with memory and there's a bit of duplication; in particular, the layout config is copied for each window:

// Layout is cloned from config so each notification can have its own mutable copy.
// This is pretty much just so we can change some params on LayoutBlocks, which is a bit
// wasteful, but easy.
pub layout: Option<LayoutBlock>,
which can be a few kb depending on config. Still, this is nothing compared to the cost of spawning a window so I haven't been too concerned.

I am surprised to see SIZE be so large, but again this isn't actually that crazy because rust static links by default. How big is your Wired executable? Maybe we could look at replacing some dependencies...

@0323pin
Copy link
Contributor Author

0323pin commented Dec 20, 2021

Thank you for your reply.

There are some community efforts for systemd services (#34)

As I'm on NetBSD, I don't really care about systemd, as long as it's an option and not a headache :)

How big is your Wired executable?

wired │ File │ │ 1 │ 1259381 │ false │ rwxr-xr-x │ root │ wheel │ 3,631,200

Actually, I've found what's going on. If, I logout and login again, there's only one process running. But, a new gets added if I reload my WM configuration. This is what is happening now, as I'm slowly going through a few configuration changes and I'm reloading it to check the effect of these.

EDIT: I think one should look at RES and not SIZE. SIZE is the maximum memory allocated to the process, RES is the acual memory being used by the process.

@0323pin
Copy link
Contributor Author

0323pin commented Dec 21, 2021

@Toqozz I don't know if you had the time to check memory usage on your system but, I'm closing this issue now as the issue with several running instances was just a side effect of WM restart.

Using wired-notify together with citron for on-demand notifications. Thanks for providing this daemon.

@0323pin 0323pin closed this as completed Dec 21, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants