<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=us-ascii" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Hi Eddie and all,<br>
thanks for doing and sharing this great job that is Click.<br>
If it's not too late, I would like to suggest some possible and
valuable (I hope .-) improvements to Click;<br>
some of them, probably, have been already discussed then it'll be one
additional vote for these.<br>
<br>
1) <u>the multi-threading support in user-level Click</u> for
performance reasons.<br>
I think that even in user-space, Click could be very very efficient
with multiple threads; certainly<br>
for SMP machines using Intel Core Duo for instance but also for single
CPU machines (where<br>
threads are blocked on multiple I/O devices and where poll()/select()
may be clearly used less or event not at all).<br>
<br>
My impression is that, because it works already with the kernel version
(and things like spin-locks)<br>
it should be achievable.<br>
<br>
2) <u>the run-time reconfiguration capability</u> of Click to get a
better flexibility<br>
in creating/removing new elements and connections.<br>
<br>
The use case is the following: a new data flow enter the Click process
and I would like to<br>
create a new socket element that would be used as a proxy for some
other running processes;<br>
In addition to the creation of this new element, I need then to add a
connection between the new element<br>
and one other element. This case may happen more than once but I don't
know in advance how many times.<br>
<br>
The point is that I would like to create at run-time new elements and
connections to these elements<br>
without using the hot-swap feature which is nice but a little bit too
heavy for my need; because it swaps all<br>
the current elements and connections.<br>
<br>
Then, I know you have already add_element() and add_connection() in
Router class<br>
but it's only possible to use them when the router is in ROUTER_NEW
state, then definitely not<br>
when all the stuff is really processing packets at run-time. Btw it
would be nice to have also remove_element()<br>
and remove_connection().<br>
<br>
3) related to the previous one, the <u>dynamic loading capability of
new element at run-time</u>.<br>
This dynamic loading capability (already present through the usage of
requirement statements) would be useful when<br>
a new element is instantiated because the binary object that contains
this element has not been linked yet with<br>
the Click process.<br>
<br>
that's all folks.<br>
Best regards,<br>
Stéphane.<br>
<br>
Stéphane Ménoret<br>
Software Architect<br>
Collaboration Technologies Laboratory (LINC)<br>
THALES Research & Technology France<br>
<br>
<br>
<br>
<br>
Eddie Kohler a écrit :
<blockquote cite="mid464B5EA2.6070808@cs.ucla.edu" type="cite">
<pre wrap="">Hi all,
I am preparing for a 1.6.0 "stable" Click release. The anonymous CVS
has been updated with a NEWS file describing my take on the changes
since 1.5.0. In the coming days I will attempt to go through enqueued
Click mailing list mail and fix what I can. Please, if you really want
something fixed, or you have any complaints, now is the time to send them.
A linked list template (one of the things I wanted to include) will not
make it into this release. Sorry Jason.
Eddie
_______________________________________________
click mailing list
<a class="moz-txt-link-abbreviated" href="mailto:click@amsterdam.lcs.mit.edu">click@amsterdam.lcs.mit.edu</a>
<a class="moz-txt-link-freetext" href="https://amsterdam.lcs.mit.edu/mailman/listinfo/click">https://amsterdam.lcs.mit.edu/mailman/listinfo/click</a>
</pre>
</blockquote>
<br>
</body>
</html>