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.

Sign up for GitHub

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

Jump to bottom

lurklib 'sleeps' without channel activity and fails to send messages to the channel #33

Open
e00E opened this issue Dec 22, 2012 · 1 comment · May be fixed by #34
Open

lurklib 'sleeps' without channel activity and fails to send messages to the channel #33

e00E opened this issue Dec 22, 2012 · 1 comment · May be fixed by #34

Comments

@e00E
Copy link

e00E commented Dec 22, 2012

This is kind of a strange bug, so I hope you understand it from my explanation.
It seems that when sending messages to a channel (i only tested it that way, might happen otherwise too) with the function privmsg, under some conditions lurklib will not send the messsage on time, but later.

Setup:
Every ten minutes I do the following out of a thread:
print('sending message')
bot.privmsg( channel, message)
print('finished sending')

I expect to see 'sending message', and 'finished sending' as ouput and the message should show up in the channel.
This sometimes work, but often not. The condition I observed is the following:
When there is no activity in the channel at all (no joins, no one talking, etc) and I let the program run for 30 minutes, I expect to see the above output 3 times, and the message in the channel 3 times.

However what I get is this:
sending message
sending message
sending message

and no message in the channel nor 'finished sending'. For some reason the call to privmsg blocks and is never finished.
When someone then writes something in the channel,or a nick is changed, etc, lurklib seems to 'wake up' and I see the message being sent to the channel 3 times and the program outputs finished sending 3 times.
The call to privmsg only finishes after there was some activity in the channel.
JeSuisAbraham added a commit to JeSuisAbraham/lurklib that referenced this issue Aug 22, 2013
@JeSuisAbraham @simark
Fix block on PING request
ce2abc7 
This patch fixes the indefinite hold of the lock following a PING message

The _raw_recv and _mcon now respond to a PING message like all the other messages and will not block
This blocking would prevent the bot from performing "send" (and other) requests until activity unblocked the bot

This fix moves the PONG answer to the recv function where all the other messages processing takes place and returns the None event (no further processing required)

Fixes jamieleshaw#33
@JeSuisAbraham JeSuisAbraham linked a pull request Aug 22, 2013 that will close this issue
Open
@JeSuisAbraham
Copy link

Hi e00E,

I had a similar issue as yours and found the culprit (and potential solution ;)

Basically, the bot checks every 10 milliseconds if there is new data to read and if there is, reads it.
The problem arises when the bot receives a PING request. Since there is new data to read, it tries to read it. But PING requests are handled differently.
The bot will only return to the main loop when it receives a message that is not a PING request. While it waits, the global lock is held and any call made from another thread to the bot will block.
My proposed solution is to handle the PING requests like all the other messages and return to the main loop immediately.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Fix block on PING request JeSuisAbraham/lurklib
2 participants
@e00E @JeSuisAbraham