Menu
▾
▴
#4 Add waitForAny to control module
Here is a new package for your consideration: control. I would be happy with a different name,
but this is how it was originally named on the Wiki.
For now, it contains only one method: waitForAny, which implements a [vwait] for multiple
variables. It has been significantly enhanced over the version in the Wiki, in that it now returns a
list of the tokens waited for which have now changed, or "timeout" if a timeout occurs. With this,
you can build a robust queue of multiple outstanding asynchronous events, e.g. http or SOAP
commands.
If you consider this a worthy package, but lacking in an area or two, let me know and I'll be happy
to work on it further. Here are some ideas for enhancement:
* replace "magical" timeout value recognition with switch, e.g. '-timeout xxx'
* add try_catch_finally. I have seen and used the "trycatch" package, but I believe it is more
complicated than it needs to be. The Wiki has a good one that we could use here. When I need
it, I'll probably add it.
Regards,
Ken Cox
control package with tests
Logged In: YES
user_id=80530
Note that the control module is now created.
Addition of this command and others will be
taken up later.
Logged In: NO
It would be nice to have a semaphore package, such that
one could direct all callbacks to trigger semaphores.
This way, even if a pacakge does not support a "wait any"
mechanism, the semephore package could trap all callbacks
and provide a wait any mechanism.
this technique could be used for
- file events
- http::geturl
- email::send
- timers
... the list goes on.
Anyone could thus create a package with callback, and not
have to reveal internal variables for use with a waitany
command. The semaphore package could then provide a waitany
on its internal variables and there would not have to be any
breaching of encapuslation.
Logged In: NO
It would be nice to have a semaphore package, such that
one could direct all callbacks to trigger semaphores.
This way, even if a pacakge does not support a "wait any"
mechanism, the semephore package could trap all callbacks
and provide a wait any mechanism.
this technique could be used for
- file events
- http::geturl
- email::send
- timers
... the list goes on.
Anyone could thus create a package with callback, and not
have to reveal internal variables for use with a waitany
command. The semaphore package could then provide a waitany
on its internal variables and there would not have to be any
breaching of encapuslation.
Logged In: YES
user_id=80530
Do you have a reference for precisely what you mean
by a "semaphore" ? Would that be an alternative to
wait-for-any, or something to have in addition to
wait-for-any?
Logged In: YES
user_id=80530
In particular, is FR 454718 what you are talking about?
Logged In: YES
user_id=304001
Yes, FR 454718 is what I was talking about.
To explain a little further...
If a wait-any concept is added to TCL, it would be very useful, but only to implimentations
within a given package. If a user of many packages wished to wait for one of many package
call to complete, and only had the wait-any method available to them, they would be required
to know the variables in each package that they should wait on. In my opinion, any requirement
for unpublished vairable names within a package is a violation of the intent of the package construct.
I think that a better approach would be to have a consolidated wait-any *package* that can be
invoked (signalled) by a call-back from an underlying package. This way, the developer would not
be required to know about internal variables, they could use a wait-any concept, and they could wait
for one of any event accross a number of packages.
Furthermore, developers of new packages need only impliment a call-back, and this would fully support
a multi-package wait-any method. No other special consideration need be done by the package developer.
Just my thoughts on this.
Evan,
Logged In: YES
user_id=246646
I would agree that a general wait-for-any package would be more useful, and would make it easier for a
client to avoid breaking encapsulation. However, I propose moving forward with this implementation
anyway, because:
* the proposed alternative, the Semaphore package (in FR 454718) does not exactly manage semaphores,
in the meaning of Solaris sem_wait(3R) and sem_post(3R). The API just does not seem finished and working
and tested.
* the proposed Semaphore package does not solve the wait-for-any problem, which this package has
solved. Thus, this work is necessary anyhow, and we merely disagree over the eventual package layout.
Future package could use this wait-for-any implementation.
* a general purpose callback mechanism would be difficult at best to get widely deployed. The http and
fileevent applications mentioned are already well established in the core Tcl distribution. To retrofit them to
use a general purpose mechanism would require volunteers and wide buy-in. It would require design and a
detailed audit to ensure no existing code would break as a result. Such an effort does not seem
cost-effective to me.
* a client could avoid breaking encapsulation using the existing APIs together with this API. That is, a
client could register a callback with the http package, set a client-specific variable, and wait for that
variable, avoiding the use of the undocumented $token(status) variable.
Logged In: YES
user_id=304001
Kenstir stated:
* the proposed alternative, the Semaphore package (in FR 454718) does not exactly manage
semaphores, in the meaning of Solaris sem_wait(3R) and sem_post(3R). The API just
does not seem finished and working and tested.
-------------------
I'm not sure what documentation regarding Solaris that you were reading, but the proposed
semephore package does adhere to the functional description of sem_wait(R3) and sem_post(R3)
of the Solaris man pages.
There may be some difficulty in a threaded TCL environment, but that was highlighted in the
FR 454718.
------------
Kenstir stated:
* a client could avoid breaking encapsulation using the existing APIs together with this API.
That is, a client could register a callback with the http package, set a client-specific
variable, and wait for that variable, avoiding the use of the undocumented $token(status)
variable.
-----------------
I think that you were using this as an example of how the wait-for-any would work, and it is
also an excelent example of how the semephores would work. Your description of how
you could make a callback routine that modifies its own variables and then use wait-for-any to
wait for these variables, is basically the way that a semephore package would work.
The wait-for-any command is merely a more convenient way of implimenting a semephore
package. The package would be better off standard, rather than requiring that everyone
impliment thier own. Since http, fileevents, timers and many other tcl packages use callbacks,
there would not need to be *any* change to any code, just the way that we use the code.
See below how the already existing http package could be used and waited for via the
semephore package.
--- example TCL ---
set afterName [after 10000 Semephore::Signal timoutName]
set URLToken [http::geturl $someURL -command Semephore::Signal]
if {[Semephore::Wait *] == timeoutName} then {
http::reset $URLToken timout
} else {
after cancel afterName
processHTTP $URLToken
}
The bottom line here is that I was trying to stimulate a waiting package for the
TCL Standard Library. I did not wish to make any changes to the core TCL code, since this is the feature
request for tcllib.
I was hoping that since the semephore package was so small and straight forward that it would be
easy for TCLers to extend to handle threaded tcl and include it in tcllib. I think that we agree that
in TCLs current state, waiting for one of many call-backs or events is difficult.
Logged In: YES
user_id=75003
Raising the priority of the item because its inclusion in the
upcoming release was proposed in the Tcllib-devel mailing list.
Supporting or contrarian statements should be made on the
referenced mailing list for public discussion.
Logged In: YES
user_id=80530
did not review in time for tcllib 1.4
Logged In: YES
user_id=80530
this is checked in on the DEVELOPMENT
branch now.