|
From: Jan N. <jan...@gm...> - 2025-01-15 11:36:35
|
Op wo 15 jan 2025 om 11:43 schreef Ashok:
> I do wish Jan, assuming he has read the references I posted previously, would address at least the two points I specifically asked about in my post. To quote,
>
> Per my reading of just the TLS-related portions,
> • It does not allocate slots for the *implicit* TLS entries and initialize them in the loading thread.
> • It does not update the TLS map for existing threads by reallocating (if necessary) the TLS storage and updating the in-use slot map.
See below. I never used those TLS features, and I doubt any existing
Tcl extension
uses it. Can you supply (or point to) a little bit of example code?
> If the intent is to have memory loading work for a restricted set of extensions (say no exception handling or implicit TLS) because that is useful enough to accept current risk and future risk in case of Windows changes, folks can by all means vote yes. Please do add test cases though to avoid a repetition of the zipfs situation before 9.0.
Regarding exception handling, I can be very short: the Tcl core
doesn't handle (C++) exception handling, if it is thrown from a dll
or from anywhere else. Any exception thrown internally in a dll, must
be caught within the same dll, and translated
to TCL_OK or TCL_ERROR with an error-message. The throw/catch handling
is fully within the loaded dll, which
is handled by Pull request #91. So, it should work in MemoryModule.
Two questions:
1) Can you supply a piece of test-code you suspect that won't work?
2) Can you point to any Tcl extension dll in the field using this?
Regarding TLS, same question:
1) Can you supply a piece of test-code you suspect that won't work?
2) Can you point to any Tcl extension dll in the field using this?
The future risk in Windows Changes: I don't see that happen. The
changes in Vista were
probably either for security reasons, or for extension to x64, both
are being used a long time
now in various Windows versions. I don't see the need for more changes
coming. Next
change in the Windows kernel is probably the switch to the Linux kernel.
The LUCK framework supports the following (more than 150!) dll's being loaded
by MemoryModule:
---------------------------------------------------------------------------
app-sdx2.0 augeas0.5.0 autoopts0 awthemes10 azure-ttk bcrypt2.0
blt2.4 bonjour1.1 BSD1.9.2 bwidget1.10 bz20.1 calc0 can2svg0.3
Canvas3d1.2.4 ceptcl0.4 classview0.1 dbus DiffUtil0.4.2 dmtx0.7.5
espeak0.2 Ffidl0.7 flexmenu1 forest-ttk fsdialog1.15
fswatch2.0.1 fuse1.1 gridplus2.11 helpviewer3.0.2 icons2
Img1.4.11 imgjp20.1 itcl4.2.0 itk4.1.0 iwidgets4.1 kafka2.4
legacy_3dcanvas lmdb0.4.3 lzma0.1 materialicons0.2 Memchan2.4
mkappimg modbus0.1 Mpexpr12 mqtt2.0 mqtt3.1 msgpack2 nats3
notebook2.2 nsf2.4.0 ooxml1 parse_args0.5.1 parser1.8 pdf4tcl09
pdf4tcl_graph1.0 photoframe1 piio1.3 pikchr1.0 promise1
pty_tcl0.1 puppyicons0.1 ral0.12.2 ralutil0.12.2 retcl0 rhash0.1
rl_json0.15.1 Rtcl1.2.2 scrolldata2 sdx1.0 snack2.2 snap70.1
sqlite3.47.2 stardom0.42 starsync1.0 stbimage1.2 stringfileinfo0.2
sun-valley-ttk tangoicons0.1 tbcload1.7 tclcan0.1
tclcompiler1.7.1 tclcsv2.4.3 TclCurl7.22.0 tclepeg0.4
tclJBlend2.1.0 tcllib1.21 tcllibc1.21 TclMagick0.46 tclrmq1.4.5
tclsoap1.6.8 tcltaglib1.1 tcluvc0.1 tclws2 tclx8.6 tdbc1.1.1
tdbcjdbc0.2 tdbcmysql1.1.5 tdbcodbc1.1.1 tdbcpostgres1.1.1
tdom0.9.3 tfirmata thread2.8.5 tile-extras Tix8.4.3 tkbugz
tkchat1.500 tkcon2.7 tkconclient1.0 Tkhtml3.0 tkinspect5.1.6
tkled0.1 tklib0.7 TkMC1.0 tknotebook0.1 tkpath0.3.3
tksqlite0.5.13 tksvg0.14 Tktable2.11 tkvlc0.8 Tkzinc3.3.6
tls1.6.9 tnc0.3.0 tomato1 topcua0.5 touchcal0.1 treectrl2.4.2
Trf2.1.4 trofs0.4.9 tserialport1.1 ttk-themes twdbgi0.1 udp1.0.11
ukaz2.1 ulis unqlite0.3.8 upnp0.2 v4l20.1 vcd0.1 vectcl0.3
VecTcLab vectcltk0.2 vfs1.4.2 vnc0.5 vqtcl4.1 vu2.3 WavReader0.1
wibble0.4 wscope-1.0b www2 xdgicons1.0 yeti0.4.2
---------------------------------------------------------
I suspect that none of them use exception handling or TLS. If you show me some
example code, I'm more than happy to include that as an additional testcase.
Thanks!
Jan Nijtmans
|