It is also exported through the public stub table.
Its description however indicates that it is more
an internal function required for the initialization
of the memory allocation subsystem (MAS) of the
core.
IMHO making it public makes sense only if we allow
the replacement of the MAS by an external system.
Something I consider unlikely.
Hm, ports to PDA's ? ... No, not even for such.
They most likely will use a different allocator,
yes, but that is part of the porting work. The
change is not externally visible.
So, my recommendation for now is to not to
document this function and to make it internal
in the next major release of the core.
I will assign this now to Jeff to get his
opinion too.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have very little experience with stub exported calls.
It is definitely so that above are to be used only internally
and should therefore be named as TclpGetAllocMutex or such.
They should not be exported.
So what to do? Wait for 9.0 and scrap them out of the
public API?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I agree (given comments here) that it probably should be called TclpGetAllocMutex, and should have MODULE_SCOPE, but who knows who is calling it? :-( So, I suggest doing the rename and then creating a wrapper function (called Tcl_GetAllocMutex) that calls the real function. (Maybe while printing a message stderr that an unsupported/deprecated API has been called?) There should also be a comment in tcl.decls beside the function declaration that indicates that the function is deprecated and likely to be removed in 9.0.
With that done, open a separate FRQ ticket to remind us to revisit this (i.e. remove the function) for 9.0, which is when we allow that sort of ABI change. With *that* done, close this ticket.
Does this make things clear?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
8/9/99 (internal api change) Removed the TclpMutexLock and TclpMutexUnlock
APIs and added a new exported api, Tcl_GetAllocMutex. These APIs are all for
the mutex used in the simple memory allocators. By making this change
we are able to substitute different implementations of the thread-related
APIs without having to recompile the Tcl core. (welch)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
It seems to me that the right thing to do is to switch this to a call in the internal stubs table; anything poking this deep needs to beware the dragons anyway. Hence it is better not documented (other than perhaps in comments in tclInt.decls and the rest of the sources).
Dropping prio; no way should this block the 8.5.2 release!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Logged In: YES
user_id=75003
It is also exported through the public stub table.
Its description however indicates that it is more
an internal function required for the initialization
of the memory allocation subsystem (MAS) of the
core.
IMHO making it public makes sense only if we allow
the replacement of the MAS by an external system.
Something I consider unlikely.
Hm, ports to PDA's ? ... No, not even for such.
They most likely will use a different allocator,
yes, but that is part of the porting work. The
change is not externally visible.
So, my recommendation for now is to not to
document this function and to make it internal
in the next major release of the core.
I will assign this now to Jeff to get his
opinion too.
Logged In: YES
user_id=95086
Originator: NO
I have very little experience with stub exported calls.
It is definitely so that above are to be used only internally
and should therefore be named as TclpGetAllocMutex or such.
They should not be exported.
So what to do? Wait for 9.0 and scrap them out of the
public API?
Logged In: YES
user_id=79902
Originator: YES
I agree (given comments here) that it probably should be called TclpGetAllocMutex, and should have MODULE_SCOPE, but who knows who is calling it? :-( So, I suggest doing the rename and then creating a wrapper function (called Tcl_GetAllocMutex) that calls the real function. (Maybe while printing a message stderr that an unsupported/deprecated API has been called?) There should also be a comment in tcl.decls beside the function declaration that indicates that the function is deprecated and likely to be removed in 9.0.
With that done, open a separate FRQ ticket to remind us to revisit this (i.e. remove the function) for 9.0, which is when we allow that sort of ABI change. With *that* done, close this ticket.
Does this make things clear?
Logged In: YES
user_id=95086
Originator: NO
All is clear.
Logged In: YES
user_id=79902
Originator: YES
Looking in the 'changes' file, I see this:
8/9/99 (internal api change) Removed the TclpMutexLock and TclpMutexUnlock
APIs and added a new exported api, Tcl_GetAllocMutex. These APIs are all for
the mutex used in the simple memory allocators. By making this change
we are able to substitute different implementations of the thread-related
APIs without having to recompile the Tcl core. (welch)
Logged In: YES
user_id=79902
Originator: YES
It seems to me that the right thing to do is to switch this to a call in the internal stubs table; anything poking this deep needs to beware the dragons anyway. Hence it is better not documented (other than perhaps in comments in tclInt.decls and the rest of the sources).
Dropping prio; no way should this block the 8.5.2 release!