cis-kuldeep/PyBitmessage-2021-04-27
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity

Merge pull request #73 from Atheros1/master

Browse Source 
Recover when user sends many messages but then quickly closes/restarts Bitmessage
This commit is contained in:
Jonathan Warren 2013-03-26 09:46:08 -07:00
commit da7320d94c
1 changed files with 13 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

15
bitmessagemain.py
View File

@ -136,7 +136,7 @@ class outgoingSynSender(QThread):
rd.setup(sock,HOST,PORT,self.streamNumber,self.selfInitiatedConnectionList,objectsOfWhichThisRemoteNodeIsAlreadyAware)
rd.start()
printLock.acquire()
print self, 'connected to', HOST, 'during outgoing attempt.'
print self, 'connected to', HOST, 'during an outgoing attempt.'
printLock.release()
sd = sendDataThread()
@ -2445,7 +2445,18 @@ class singleWorker(QThread):
sqlLock.release()
for row in queryreturn:
toripe, = row
neededPubkeys[toripe] = 0
#It is possible for the status of a message in our sent folder (which is also our 'outbox' folder) to have a status of 'findingpubkey' even if we have the pubkey. This can
#happen if the worker thread is working on the POW for an earlier message and does not get to the message in question before the user closes Bitmessage. In this case, the
#status will still be 'findingpubkey' but Bitmessage will never have checked to see whether it actually already has the pubkey. We should therefore check here.
sqlLock.acquire()
sqlSubmitQueue.put('''SELECT hash FROM pubkeys WHERE hash=? ''')
sqlSubmitQueue.put((toripe,))
queryreturn = sqlReturnQueue.get()
sqlLock.release()
if queryreturn != '': #If we have the pubkey then send the message otherwise put the hash in the neededPubkeys data structure so that we will pay attention to it if it comes over the wire.
self.sendMsg(toripe)
else:
neededPubkeys[toripe] = 0
self.sendBroadcast() #just in case there are any proof of work tasks for Broadcasts that have yet to be sent.