TIP: Click on subject to list as thread! ANSI
echo: synchronet
to: deon
from: Digital Man
date: 2022-05-08 11:28:00
subject: MsgBase first_msg propert

  Re: MsgBase first_msg property.
  By: deon to Digital Man on Sun May 08 2022 10:41 pm

 >   Re: MsgBase first_msg property.
 >   By: Digital Man to deon on Sat May 07 2022 09:44 am
 >
 >  > Currently, I'm not scrubbing any cached values (namely, the contents of
 >  > the SMB "status header", which includes such things as the last message
 >  > number). The first message number must be queried every time the property
 >  > is read, that value is not cached in any SMB data structure.
 >
 >  >  > I know I can create new variables with those values that I need, but
 >  >  > that does seem a waste when I have a variable that has this object
 >  >  > already (especially if it is updated when I reopen the message base).
 >
 >  > You can look at js_msgbase.c if you're curious how/why it works the way
 >  > it does and offer suggestions, but right now, it's working as designed
 >  > and expected.
 >
 > OK, thanks for the guidance - I see what's going on now.
 >
 > Would you be adverse to something like this:
 >
 > diff --git a/src/sbbs3/js_msgbase.c b/src/sbbs3/js_msgbase.c
 > index d52c7000f..8df7a7d9c 100644
 > -+- a/src/sbbs3/js_msgbase.c
 > +++ b/src/sbbs3/js_msgbase.c
 > @@ -2967,6 +2967,7 @@ static JSBool js_msgbase_get(JSContext *cx, JSObject
 > *obj, jsid id, jsval *vp)
 >         idxrec_t        idx;
 >         private_t*      p;
 >         jsrefcount      rc;
 > +       static uint32_t first_msg = 0;

I would be adverse, yes, as static variables are shared among on threads (e.g. nodes) and if you opened 2 message bases, that variable would be stomped on by the second opened message base. That's not going to work.

 > IE: I'm hoping the smb.status header retains it's values when the msgbase is
 > closed (and you can trust those values as correct as at the time of
 > closure).

The smb.status header is not cleared when the msgbase is closed. But that's sort of what I was proposing: it should be. Or at least js_msgbase_get() should return 'undefined' for those properties when the message base isn't open to let you know that you've done something unexpected.

 > I'm assuming this wont affect anything else, given that you can
 > see if the message base is open (and thus the values are current), if
 > "is_open = true".

I've added a proper caching of the last-read 'first_msg' value (caching it in the object's private data). I'll commit that now. Give it a try and let me know if it does what you were hoping for.
-- 
                                            digital man (rob)

This Is Spinal Tap quote #46:
"Not an Exit" - we don't want an exit. Well that's true.
Norco, CA WX: 64.1øF, 64.0% humidity, 11 mph S wind, 0.00 inches rain/24hrs
--- SBBSecho 3.15-Linux
                                                
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

SOURCE: echomail via QWK@pharcyde.org

Email questions or comments to sysop@ipingthereforeiam.com
All parts of this website painstakingly hand-crafted in the U.S.A.!
IPTIA BBS/MUD/Terminal/Game Server List, © 2025 IPTIA Consulting™.