From: Donald G Porter <donald.porter@ni...> - 2009-07-15 23:19:25
Alexandre Ferrieux wrote:
> Hi Jan,
> I'm really ignorant about const-nightmares. I would just like a tiny
> piece advice on how to handle CONST86 qualifiers that are present in
> the generic stubs stable and thus could be accessed by extensions.
> More concretely, Thread has a bunch of warnings due to not using the
> qualifier when calling Tcl_GetObjType and assigning the result.
> So: should extensions use CONST86 too ? (I know it is a compile-time
> value, but it doesn't affect the ABI, right ?)
The statements tossing warnings all seem to be examples of what
I called "Type II" when giving migration advice for CONST84.
See http://wiki.tcl.tk/3669 .
That said, these all appear to be calls to Tcl_GetObjType() which we
have increasing agreement is a dicey thing at best for extensions to
be calling. Especially bad that there appears to be no safety checks
for NULL returns.
If Thread really needs access to the internals of the Tcl_ObjTypes
defined by Tcl itself, should Thread really get on a path to just
become part of Tcl?
| Don Porter Mathematical and Computational Sciences Division |
| donald.porter@... Information Technology Laboratory |
| http://math.nist.gov/~DPorter/ NIST |
On 16.07.2009, at 01:19, Donald G Porter wrote:
> If Thread really needs access to the internals of the Tcl_ObjTypes
> defined by Tcl itself, should Thread really get on a path to just
> become part of Tcl?
In my experience...
A simplified (i.e. a partial) version could be incorporated.
Just the ability to create singleton threads and exchange
messages. Adding all that is in the threading extension now
is kind of difficult to maintain and it is not really needed
for majority of users. As of that, peraphs the better is to
combine the singleton thread and thread pool and integrate
just the thread pool. The pool with just one worker is effectively
equal to the singleton thread. And, threadpool is much more
versatile and flexible, of course.