Re: CPU Hog
  By: deon to Digital Man on Fri Aug 05 2022 04:52 pm

 > Howdy,
 >
 > Today I discovered SBBS with 2 threads both running at 98% CPU - having
 > stopped and restarted SBBS, its all back to normal.
 >
 > At the same time, my fido hub alerted me to my system being "slow" and
 > refusing packets. Curious, I looked through the logs and indeed it seems
 > that when I polled my fsxhub, mail flowed normally, but when I polled my
 > fido hub, it was stuck there receiving a file:
 >
 > Authentication successful:
 > Attempting poll for node 3:633/280@fidonet
 > JSBinkP/4 callout to 3:633/280@fidonet started
 > Connecting to 3:633/280@fidonet at ftn633.vk3heg.net:24554
 > Peer version: binkd/1.1a-115/Linux
 > Will encrypt session.Authentication successful: secure
 > Receiving file: /opt/sbbs/temp/e8c38a06.pkt (1.4KB)
 > [no more output]
 >
 > It doesnt appeaer that this thread dies - (and it should time out after 5
 > minutes right?) I ran "binkit -p" and it's still stuck on this node after 20
 > mins.
 >
 > My fido hub is set to "Poll: Yes", so I'm suspecting everytime my system was
 > polling, the old thread hadnt died yet, so eventually I end up with many
 > threads tied up polling my fido hub.
 >
 > So, shouldnt it ultimately time out after 5 mins?

It "should" timeout, yes (I don't know the expected timeout duration), but I also didn't write binkit/binkp.js, so I'd have to track down that bit of code and see what its doing to be sure.

 > Is there a way to "busy out" the polled node, so another thread doesnt try
 > and call it again?

The SBBS event thread is a single thread. BinkIt polling is normally done as a timed event, which is run as in the foreground of that single event thread. So I'm not clear what "another thread" would be.
-- 
                                            digital man (rob)

Rush quote #66:
He's old enough to know what's right, but young enough not to choose it
Norco, CA WX: 89.6øF, 37.0% humidity, 6 mph SSW wind, 0.00 inches rain/24hrs
--- SBBSecho 3.15-Linux