search

pingryiRT / P2PPlatform

A python P2P library backend used to build P2P applications
The Unlicense
0 stars 0 forks source link

Alerters should be called on new threads #13

Open jorndorff opened 6 years ago

jorndorff commented 6 years ago

Each alerter should be called on its own thread so that long-running alerters don't block subsequent alerters or the normal operation of the Network's autoReceiver.

mpavlak2018 commented 6 years ago

I was thinking about this more, and I think it will be harder to do this than we're thinking—reason being, we will probably have overlapping threads and resource conflicts (if one starts and the another message is received it may try that alerter before the previous thread is finished with it)... Especially with the way we are thinking of using a message string and integrating all of the raw inputs into that main loop on interface, I can see a lot of problems developing (like another thread changed that message string before the prior was finished, and messages are skipped and others are repeated twice...)

jorndorff commented 6 years ago

Okay, good points.

Are any of those problems that can't be solved by properly implementing locks in the client (eg the chat interface, or distributed computing network)?

Perhaps a good design suggestion for clients would be to keep the runtime of their alerters short, like just long enough to add the message to some kind of queue. Thoughts?

On Tue, Oct 3, 2017 at 5:36 PM, mpavlak2018 notifications@github.com wrote:

I was thinking about this more, and I think it will be harder to do this than we're thinking—reason being, we will probably have overlapping threads and resource conflicts (if one starts and the another message is received it may try that alerter before the previous thread is finished with it)... Especially with the way we are thinking of using a message string and integrating all of the raw inputs into that main loop on interface, I can see a lot of problems developing (like another thread changed that message string before the prior was finished, and messages are skipped and others are repeated twice...)

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/pingryiRT/P2PPlatform/issues/13#issuecomment-333986054, or mute the thread https://github.com/notifications/unsubscribe-auth/ARfKWjG3vB17gDl97vyO8iSVzx5lEK_Fks5soqjjgaJpZM4PszQA .

jorndorff commented 6 years ago

Or maybe instead of callable alerters, the client should pass in a queue to which the Network just directly appends the received message. Then the client can handle the queue however makes most sense in its own main loop?

On Tue, Oct 3, 2017 at 5:43 PM, Orndorff, Josh jorndorff@pingry.org wrote:

Okay, good points.

Are any of those problems that can't be solved by properly implementing locks in the client (eg the chat interface, or distributed computing network)?

Perhaps a good design suggestion for clients would be to keep the runtime of their alerters short, like just long enough to add the message to some kind of queue. Thoughts?

On Tue, Oct 3, 2017 at 5:36 PM, mpavlak2018 notifications@github.com wrote:

I was thinking about this more, and I think it will be harder to do this than we're thinking—reason being, we will probably have overlapping threads and resource conflicts (if one starts and the another message is received it may try that alerter before the previous thread is finished with it)... Especially with the way we are thinking of using a message string and integrating all of the raw inputs into that main loop on interface, I can see a lot of problems developing (like another thread changed that message string before the prior was finished, and messages are skipped and others are repeated twice...)

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/pingryiRT/P2PPlatform/issues/13#issuecomment-333986054, or mute the thread https://github.com/notifications/unsubscribe-auth/ARfKWjG3vB17gDl97vyO8iSVzx5lEK_Fks5soqjjgaJpZM4PszQA .

jorndorff commented 6 years ago

@mpavlak2018 What are your thoughts on the merits of using a queue vs an alerter?

This may be related to how a Network informs an Interface about things other than messages eg ("Failed to connect to peer", "Invalid message from Bob ignored")