Forum OpenACS Development: Re: corba client in openacs

Posted by Gustaf Neumann on
Can you be more specific, what "aolsever has problems with Itcl" means?

Maybe this means "itcl not thread safe". If this is so, the next question is if this is a problem for your application? If you find a way to run a single itcl proc at one time, this might not be a show stopper. The most probably most efficient way (in terms of lines-of-code and performance) would be to start a thread (using libthread and xotcl-core) and delegate corba interactions to that thread (i could send examples how to set this up).

But this is already too much guessing from my side.

-gustaf neumann

Posted by Michal Hanckowiak on
thanks for your reply, Gustaf ;);

> Can you be more specific, what "aolsever has problems with Itcl" means?

when I load Itcl in tcl/...-proc.tcl file in some oacs package,
then it is NOT available in aolserver threads handling http requests
(probably aolserver does not add "something" to blueprint??)

as a result I must add "package re Itcl" before
every piece of code using Itcl (which is tedious)
and may also slower handling of http requests
becouse Itcl is loaded on request, not on server starting...

I think that Itcl IS thread-safe, see

could you send an example how to start a thread
by libthread and xotl-core
(and how -conn:* threads can communicate with it?
(probably by nsv vars?))


Posted by Gustaf Neumann on
Dear Michal,

Write to following into a file eg. xowiki/tcl/sample-thread-procs.tcl

::xotcl::THREAD create sample-thread {
  # The following commands are used to initialize the thread. The
  # defined procs, classes and objects are available once the thread
  # is running and keep their state. One can use in the initialization
  # as well "package require ...." for packages that should be
  # available in the thread.
  Class create Counter -parameter {{value 1}}
  Counter instproc ++ {} {my incr value}
  Counter c1
  Counter c2
} -persistent true

# The commands in the thread can be executed via
#     sample-thread do /cmd/
# where /cmd/ is a Tcl command (with possibly several arguments).  The
# following command will execute "c1 ++" in the sample-thread and
# return its result. The thread is started the first time the
# sample-thread is addressed.
#     set x [sample-thread do c1 ++]
# The invocation can be simplified by using e.g. a forwarder:
#     sample-thread forward ++ %self do c1 ++
# With this forwarder defined, one can use e.g. 
#     set y [sample-thread ++]
When you restart the server, the first time you issue a command sample-thread do ... the thread will be started and initialized with the blueprint and additionally the provided initialization commands. So, the first execution will be somewhat slower. Later invocations to sample-thread do ... will simply talk to the thread. So, you should be able to package-require ITcl and the corba IDLs in the initialization block. When you name the thread e.g. corba, you can do then simply corba do or define some simplifying forwarder, etc.

One can certainly define as well multiple threads this way as well by providing different names. This approach works as well nicely, if one has e.g. to use a non-thread-safe extension as long only one thread is started.

Hope this helps

-gustaf neumann

Posted by Michal Hanckowiak on
thanks Gustaf,
::xotcl::THREAD seems to be a very good idea,
... may be, it is even possible to load in it
some heavy-weighted tcl extensions, such as tclBlend
(connection of tcl and java)
that opens new possibilites: access to EJB/RMI objects
and all java packages...
Michal Hanckowiak