Forum: The Gate BBS

comReadBuf() supports an infinite timeout (0)

From Deucе@1:103/705 to GitLab note in main/sbbs on Monday, January 24, 2022 14:37:42

https://gitlab.synchro.net/main/sbbs/-/commit/0b8517e11ce52702b4c56e2926990ae456dc23f6#note_2223

This seems very dangerous since it will continue block across a disconnection/new connection. Is that the intended use case?
--- SBBSecho 3.14-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

From Rob Swindell@1:103/705 to GitLab note in main/sbbs on Monday, January 24, 2022 15:18:58

https://gitlab.synchro.net/main/sbbs/-/commit/0b8517e11ce52702b4c56e2926990ae456dc23f6#note_2224

Yeah, I mentioned the risks to the requester (Nelgin) and he tested and was okay with the change: upon disconnect, the modem is always sending *something* to the application (SexPOTS), so it always aborts this loop. Still, I made the default timeout non-zero (60 seconds).
--- SBBSecho 3.14-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

From Deucе@1:103/705 to GitLab note in main/sbbs on Monday, January 24, 2022 15:55:48

https://gitlab.synchro.net/main/sbbs/-/commit/0b8517e11ce52702b4c56e2926990ae456dc23f6#note_2225

While that works fine for his modem usage, I don't understand why he needs more than the 68 years allowed by the timeout value.
--- SBBSecho 3.14-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

From Deucе@1:103/705 to GitLab note in main/sbbs on Monday, January 24, 2022 16:02:25

https://gitlab.synchro.net/main/sbbs/-/commit/0b8517e11ce52702b4c56e2926990ae456dc23f6#note_2226

I'm also not sure why his ask is important enough to potentially break existing consumers and/or add a special-case value.
--- SBBSecho 3.14-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

From Deucе@1:103/705 to GitLab note in main/sbbs on Monday, January 24, 2022 16:04:16

https://gitlab.synchro.net/main/sbbs/-/commit/0b8517e11ce52702b4c56e2926990ae456dc23f6#note_2227

I think passing INT_MAX for infinite timeout would be *much* better than zero. --- SBBSecho 3.14-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

From Rob Swindell@1:103/705 to GitLab note in main/sbbs on Monday, January 24, 2022 17:06:07

https://gitlab.synchro.net/main/sbbs/-/commit/0b8517e11ce52702b4c56e2926990ae456dc23f6#note_2228

I did search and could not locate any caller of this function with a timeout parameter value of 0. Seemed like a safe-enough change but using INT_MAX or INT_MIN is fine too.
--- SBBSecho 3.14-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

From Nelgin@1:103/705 to Deuc¿ on Tuesday, January 25, 2022 00:42:01

On Mon, 24 Jan 2022 15:55:48 -0800
"Deuc_" <deuc_@VERT> wrote:

https://gitlab.synchro.net/main/sbbs/-/commit/0b8517e11ce52702b4c56e2926990ae456dc23f6#note_2225

While that works fine for his modem usage, I don't understand why he
needs more than the 68 years allowed by the timeout value.

If someone had told me I cannot have an invite timeout but if you set
it to 0 then it'll be 68 years, I'd have been fine with that.
--
End Of The Line BBS - Plano, TX
telnet endofthelinebbs.com 23
---
� Synchronet � End Of The Line BBS - endofthelinebbs.com
--- SBBSecho 3.14-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

Who's Online
Recent Visitors
- Mike Owens
  Wednesday, September 30, 2026 05:29:40
  from Shelby, NC via Telnet
- Centurion
  Tuesday, September 29, 2026 22:34:53
  from Berea, OH via Telnet
- Compy386
  Tuesday, September 29, 2026 22:12:48
  from Tulsa, OK via Telnet
- Heat1918
  Tuesday, September 29, 2026 22:06:36
  from Seattle, WA via Telnet
- Bob
  Tuesday, September 29, 2026 20:25:58
  from Seattle, WA via Telnet
- Sg
  Tuesday, September 29, 2026 18:22:44
  from Nashville, TN via Telnet
- Keytest
  Tuesday, September 29, 2026 10:02:45
  from Club Penguin Island, FL via Telnet
- Lurker
  Tuesday, September 29, 2026 09:36:32
  from Lansing, MI via Telnet
- Mythicmrmun
  Tuesday, September 29, 2026 09:21:45
  from Melbourne, Austraila via Telnet
- Janet6207
  Tuesday, September 29, 2026 07:57:57
  from Shelby, NC via Telnet

System Info

Sysop:	Gate Keeper
Location:	Shelby, NC
Users:	942
Nodes:	20 (0 / 20)
Uptime:	497220:23:14
Calls:	15,942
Calls today:	1
Files:	5,352
D/L today:	18 files (739K bytes)
Messages:	682,095