I have a custom celery task class that then I use in the decorator #celeryApp.task. I execute the tasks with apply_async.
My task class is:
class CeleryTask(Task):
def run(self, *args, **kwargs):
pass
def on_success(self, retval, task_id, args, kwargs):
pass
def on_failure(self, exc, task_id, args, kwargs, einfo):
pass
Then I declare my tasks like:
#celeryApp.task(base=CeleryTask)
def my_celery_task(param1, param2):
pass
And finally I execute it with apply_async
my_celery_task.apply_async(
(
'value1', 'value2'
),
countdown=2)
I would like to have all tasks based on CeleryTask to have a count down of 2.
However I don't see anywhere in the documentation how to do it. I had a look at celery.app.task:Task but there is no countdown property.
Is there anyway to have a default countdown for certain task classes?
As you pointed out, the Task class does not hold the countdown property. I think that is so mainly because the countdown is something that describes HOW the task is executed - it is not something that describes the task itself.
However, that is not the end of the world. You have a pretty good solution for this.
Implement your Task subclass that does have the "countdown" property.
Override all the methods that take "countdown" as parameter. Their implementation is trivial as they will call superclass methods, with coundown=self.m_countdown (or however you named it).
Related
I'm reading the following guide:
https://colorlesscube.com/uvm-guide-for-beginners/chapter-3-top-block/
In Code 3.2 line 24- run_test();
I realized that it supposed to execute the test, but how it know which test, and how, and why should I write it in the top block.
In Code 4.1 lines 11-14 (https://colorlesscube.com/uvm-guide-for-beginners/chapter-4-transactions-sequences-and-sequencers/):
`uvm_object_utils_begin(simpleadder_transaction)
`uvm_field_int(ina, UVM_ALL_ON)
`uvm_field_int(inb, UVM_ALL_ON)
`uvm_field_int(out, UVM_ALL_ON)
`uvm_object_utils_end
Why should I add the "uvm_field_int" , what would happend if i didn't add them, and what is "UVM_ALL_ON"?
run_test is a helper global function , it calls the run_test function of the uvm_root class to run the test case. There are two ways by which you can pass the test name to the function.The first is via the function argument and the second is via a command line argument. The command line argument takes precedence over the test name passed via the function argument.
+UVM_TESTNAME=YOUR_TEST_NAME
run_test("YOUR_TEST_NAME");
run_test function in the uvm_root uses the factory mechanism to create the appropriate instance of the umm_test class and so the test case must register itself with the factory using the macro `uvm_component_utils for the factory mechanism (create_component_by_name) to function.
class YOUR_TEST_NAME extends umm_test ;
// register the class with the factory
// so that run_test can find this class when the
// string test_name is passed to it.
`uvm_component_utils(YOUR_TEST_NAME)
.....
endclass
The run_test function then kicks of the uvm_phases (..,build_phase,connect_phase,...) starting the uvm portion of the simulation. There should be no time ticks consumed before the run_phase starts , so it is essential that run_test case is called in the initial block itself. Also we want the uvm and test bench to be ready to drive and receive data as soon as the RTL is ready for which it is essential that we start the run_test at the earliest. Any delay in doing so will generate an error.
`uvm_field_int/uvm_field_object/.. are called field automation macros. They are not mandatory in the class definition and are provided as a helper macros to ease the use of many common/routine functions of the uvm_object. Examples of thse functions in uvm_object are - copy,compare,pack,unpack,print, etc and these macros generate code to automatically use these functions.
If you are not using the uvm_object common functions leaving out these macros from the class definition will not produce any errors.
In case you implement you own version of the common operations you can also leave out these macros from the class.
UVM_ALL_ON - enables all functions like compare/copy/... to be implemented for the particular field.
link with examples -
http://www.testbench.in/UT_04_UVM_TRANSACTION.html
For example the uvm_object has a compare function which compare two instances of the same class and return true if all the variables in the class are equal.
virtual function bit do_compare( uvm_object rhs, uvm_comparer comparer );
.....
// return 1 if all the variables match
return ( super.do_compare( rhs, comparer ) &&
this.var_1 == rhs.var_1 &&
this.var_2 == rhs.var_2 &&
......
this.var_n == rhs.var_n );
endfunction: do_compare
// use in main code
if ( new_class.compare(old_classs) )
...
//instead of
if ( new_class.var1 == old_class.var1 && new_class.var2 == old_class.var2 && ... new_class.varn == old_class.varn )
...
The above compare has to be written for each class and updated and maintained for every new variable that is added to the class. This could become error prone as newer variables are added. A similar process has to be followed for all the standard functions uvm_object provides.
The field automation macro generates function to address all these functionality automatically. So doing a do_print for a class with the macros will print out all the fields without explicitly writing any code for it.
// compare/print/.. functions for class simpleadder_transaction are provided by using `uvm_field_int macro.
`uvm_object_utils_begin(simpleadder_transaction)
`uvm_field_int(ina, UVM_ALL_ON)
`uvm_object_utils_end
BUT a word of caution , the use of these macros are discouraged as they add a significant amount of code into the class.. Most of these functions may not be needed by the class yet they get generated by default.
run_test is defined in the documentation (link) as:
virtual task run_test (
string test_name = ""
)
So, in principle, you can state there the test name as a string. But what's usually done is to pass it in the command line of your simulator using the argument: +UVM_TESTNAME=TEST_NAME
The uvm_object macros are a bit more complicated. They generate several methods and more importantly they register the object in the UVM factory, which is what makes them necessary (at least if you are using, as you should, the factory to create them). Citing from the UVM Class Reference documentation (Section 20.2 Component and Object Macros):
Simple (non-parameterized) objects use the uvm_object_utils* versions,
which do the following:
Implements get_type_name, which returns TYPE as a string
Implements create, which allocates an object of type TYPE by calling its constructor with no arguments. TYPE’s constructor, if
defined, must have default values on all it arguments.
Registers the TYPE with the factory, using the string TYPE as the factory lookup string for the type.
Implements the static get_type() method which returns a factory proxy object for the type.
Implements the virtual get_object_type() method which works just like the static get_type() method, but operates on an already
allocated object.
#pytest.mark.django_db
class TestClass():
def do_setup(self):
# do setup
def test_a(self):
# do something
def test_b(self):
# do something
Before test_a and test_b test cases run I need do_setup() to be called. I am using pytest-django framework.
Kindly help.
Thanks in advance
use method/function level setup teardown
def setup_method(self, method):
""" setup any state tied to the execution of the given method in a
class. setup_method is invoked for every test method of a class.
"""
def teardown_method(self, method):
""" teardown any state that was previously setup with a setup_method
call.
"""
refer http://pytest.org/latest/xunit_setup.html#method-and-function-level-setup-teardown
I have couple of questions in relation with UVM phases build() and run(). They might be applicable to other verification methodologies as well
a> Why is the build() phase executed in top-down order. Does this mean we need to new all the components in the build() phase and then proceed with execution of build() of other sub-components instantiated in the class?
b> During the run() phase is something like super.run() called? What is the order of execution of run() phase
Yes, the build_phase() of the UVM executed in top-down order because the children don't exist until they are constructed within the build_phase() of the parent component (And the UVM recommends using the factory create() method instead of calling the constructor new() directly). The build_phase() is also executed top-down so that the parent can provide override setting that the children will use when they execute their build_phase()
The run_phase() of each component is executed concurrently with no defined order you can depend on.
You only need to call super.method() if you are extending a class an need the functionality of the base method. There is nothing inside the run_phase() of a uvm_component, so there is no need to call super.run_phase() when extending from it. You may want to call it when extending your classes from your base classes.
Since Guava's ListeningExecutorService is implemented by wrapping an existing ExecutorService, it 'decorates' the task by intercepting the execute() method. That means that if I want to use a custom PriorityQueue on the underlying ExecutorService, my comparator "sees" the decorated task as a ListenableFutureTask object instead of the original.
Is there a way to get a hold of the task that it wraps? So that the queue's comparator can use the tasks weight to determine ordering?
I assume that you're concerned with submit() rather than execute()? (See the bottom of my response.)
With a ListeningExecutorService from MoreExecutors.listeningDecorator (the kind of wrapper you refer to), you're out of luck. listeningDecorator, like most ExecutorService implementations, wraps any input to submit in a FutureTask. The normal solution to this problem is to implement AbstractExecutorService and override newTaskFor to return a custom object. That should work here, too. You'll basically be reimplementing listeningDecorator, which is a fairly trivial wrapper around AbstractListeningExecutorService, which is itself a fairly trivial wrapper around AbstractExecutorService.
There are two couple complications. (OK, there might be more. I admit that I haven't tested the approach I'm suggesting.)
AbstractListeningExecutorService doesn't allow you to override newTaskFor. (Why? I can explain if you'd like to file a feature request.) As a result, you'll have to extend AbstractExecutorService directly, largely duplicating the (short) AbstractListeningExecutorService implementation.
newTaskFor has to return a ListenableFuture that's also Comparable. The obvious choice for a ListenableFuture is ListenableFutureTask, but that class is final, so you can't make instances Comparable. The solution is to create a ListenableFutureTask and wrap it in a SimpleForwardingListenableFuture that implements Comparable.
Why do I assume you're dealing with submit() rather than execute()?
listeningDecorator(...).execute() doesn't wrap the input task, as shown by this test I just wrote:
public void testListeningDecorator_noWrapExecuteTask() {
ExecutorService delegate = mock(ExecutorService.class);
ListeningExecutorService service = listeningDecorator(delegate);
Runnable task = new Runnable() {
#Override
public void run() {}
};
service.execute(task);
verify(delegate).execute(task);
}
I would like to know the best practice to implement the follow scenarios.
public class MainWindow : Window
{
public void MainWorkflow()
{
// initiate a work-thread to run LongCompute
// when LongCompute finishes, update the corresponding GUI
// for example, change the statusbar as "Computation is done"
}
private void LongCompute()
{
// a 2-minute computation and then update member variables
// after it finishes. I expect the main thread to use the
// updated member variables to update GUI later
}
}
I am looking for a concrete good example to illustrate the best practice for this task.
As we know, the work-thread should not be used to update the GUI because GUI should be updated by the thread which created them. Also, I knew the following two modes:
Case I> The main thread waits for the worker thread and then update the GUI after than.
For example,
we can use the WaitOne method defined in AutoResetEvent in this case and it will be triggered by the Set method. But this is not a good way.
Case II> Set a callback function for the worker thread, however, the callback function is still called in the work thread which is not good for manipulating the GUI.
As #Jeff said in the comments, use a BackgroundWorker for this. You specify what function to call on the background thread, and another to call when the background work is done.