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

Refactor shisui main to support graceful shutdown #156

Closed
GrapeBaBa opened this issue Sep 16, 2024 · 5 comments
Closed

Refactor shisui main to support graceful shutdown #156

GrapeBaBa opened this issue Sep 16, 2024 · 5 comments
Assignees
Labels
enhancement New feature or request good first issue Good for newcomers help wanted Extra attention is needed

Comments

@GrapeBaBa
Copy link
Member

Currently, sub network objects don't be managed after it start, there is no place we could invoke Close function on them.

@GrapeBaBa GrapeBaBa added enhancement New feature or request good first issue Good for newcomers help wanted Extra attention is needed labels Sep 16, 2024
@r4f4ss
Copy link

r4f4ss commented Sep 16, 2024

@GrapeBaBa Can I get this issue?

@GrapeBaBa
Copy link
Member Author

@GrapeBaBa Can I get this issue?

Of course.

@Tchisom17
Copy link

I am applying to this issue via OnlyDust platform.

My background and how it can be leveraged

I’m a backend software engineer focusing strongly on Go, particularly in building decentralized systems and working with blockchain technology like Ethereum. Over the years, I have been involved in projects that require careful management of resources in distributed networks, ensuring efficient operations with minimal hardware and bandwidth requirements. In addition to working on decentralized solutions, I have optimized cloud services, automated complex pipelines, and integrated storage solutions. This background gives me a solid foundation to understand and tackle the challenges posed by peer-to-peer protocols like the Portal Network.

How I plan on tackling this issue

To address the issue of subnetwork objects not being managed after they start, I would begin by analyzing how these objects are created and why they persist without a clear shutdown process. Since the problem is the absence of a place to invoke the Close function, I’d explore introducing lifecycle management into these objects. One approach could be to utilize Go's context package to manage the lifecycle of subnetwork objects, allowing for proper shutdown signals when they’re no longer in use. Alternatively, I would look at implementing a cleanup process tied to the object’s creation or session duration, ensuring that resources are efficiently released without impacting the overall network performance. The goal would be to provide a way to manage these objects in a controlled and clean manner, avoiding unnecessary resource consumption while maintaining network stability.

@GrapeBaBa
Copy link
Member Author

I am applying to this issue via OnlyDust platform.

My background and how it can be leveraged

I’m a backend software engineer focusing strongly on Go, particularly in building decentralized systems and working with blockchain technology like Ethereum. Over the years, I have been involved in projects that require careful management of resources in distributed networks, ensuring efficient operations with minimal hardware and bandwidth requirements. In addition to working on decentralized solutions, I have optimized cloud services, automated complex pipelines, and integrated storage solutions. This background gives me a solid foundation to understand and tackle the challenges posed by peer-to-peer protocols like the Portal Network.

How I plan on tackling this issue

To address the issue of subnetwork objects not being managed after they start, I would begin by analyzing how these objects are created and why they persist without a clear shutdown process. Since the problem is the absence of a place to invoke the Close function, I’d explore introducing lifecycle management into these objects. One approach could be to utilize Go's context package to manage the lifecycle of subnetwork objects, allowing for proper shutdown signals when they’re no longer in use. Alternatively, I would look at implementing a cleanup process tied to the object’s creation or session duration, ensuring that resources are efficiently released without impacting the overall network performance. The goal would be to provide a way to manage these objects in a controlled and clean manner, avoiding unnecessary resource consumption while maintaining network stability.

Thank you for your interest, this issue has been resolved by @r4f4ss , we will create more issues and look forward to your contributions👍

@GrapeBaBa
Copy link
Member Author

fixed by #158

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request good first issue Good for newcomers help wanted Extra attention is needed
Projects
None yet
Development

No branches or pull requests

3 participants