LSI_THREAD_... - this old functions. Why not use Lsi_info(14)?

very interesting vlad... this looks undocumented and IBM admits this function is for 'debugging' and not officially supported. One reason may be as follows:

{ Link }

But I will experiment with this to gain some experience!

> Leo St-Jacques: "Not thread safe" means that this call cannot be used safely in a multi-threaded processing environment.

In LotusScript, to my knowledge, not implemented multithreading. This would apply to Java, but there is no such function.

Perhaps these bugs because they use Dom.Doc, Lotus Workflow? Moreover, these products will not be supported...

Indeed thousands of developers use this feature, and no one has no problems were observed. I have always used this function in large projects, there were no problems.

Hi Vlad,

please refer to the Designer help regarding multithreaded agents operating in the same memory space. Here is an excerpt:

"LotusScript agents run as separate threads in the same HTTP process. A process is a collection of one or more threads executing a single application.

Context switching is the act of saving the current state (hardware and software) and switching to another thread or process by restoring its state."

This means that multiple agents can operate in the same memory space (global declarations).

I have not tested this, but I suspect that LSI_Info will not discriminate (necessarily, or not supported) between instances of the same agent.

The bottom line is that while it may appear to work in certain instances, the official like is important because undocumented exceptions do exist.

Hi Mark,

If HTTP is not used?

And if in the Server Document (Server Tasks -> Agent Manager) in the field "Max concurrent agents" is set to 1?

Conditions of performance (and settings) can be different. I think that if someone uses a functional in the specific conditions and has a problem, it does not mean that others will as well.

It may of course be you are right...
But I have for years used that documentation to the 30% does not correspond to reality, and there is already some personal experience.
And also we know how IBM responds to questions (which they support) - this is sad...

@Vlad: All this discussion and still no vote?
You seem to like the idea of being able to get the callstack. You have a way to do it already, but for whatever reason it is not documented.

So IMHO you should promote the idea to get the function or equivalent (you like and use often) documented and supported officialy.

Btw I don't believe GetThreadInfo is any older function than LSI_Info. It is only the less capable but documented equivalent.

LSI_Info will give the calling function, so additional code and a global variable can be used to produce a call stack. I will likely do just this however, the contexts in which this would succeed is in question. I love the function @GetMembers (list, startIndex, numberOfListItems) but have reservations about using it, as it's not documented.

I'm inclined to believe that undocumented functions that remain so for a long time are that way because an unforseen technicality emerged during development, and fulfillment was shelved. Such as in the case of concurrent web agents and LSI_Info. I am a very heavy user of concurrent web agents.

Go on Vlad, support it! :)

PS. xpages implement a callstack