Radicalvi ricordate dell’AsyncWorker di Radical?
Ci sono delle interessanti novità, su richiesta di Ughetto ho implementato la possibilità di riutilizzare lo stesso worker più volte al fine di poter creare dei job asincroni che possono essere poi mandati in esecuzione.
Quello che è possibile fare in più ora è ad esempio questo:
[TestMethod]
[TestCategory( "AsyncWorker" ), TestCategory( "Threading" )]
public void asyncWorker_asAsyncAction_should_return_an_executable_asyncAction()
{
	var wa = new ManualResetEvent( false );
 
	var asyncAction = AsyncWorker.Using( 10 )
		.OnExecute( e =>
		{
			Thread.Sleep( 5 );
		} );
 
	var worker = asyncAction.Execute();
 
	worker.Completed += ( s, e ) =>
	{
		wa.Set();
	};
 
	wa.WaitOne();
}
è quindi possibile creare una “async action” (che non ha nulla a che spartire con Action) che poi può essere eseguita in qualsiasi momento, ma anche accantonata per usi futuri. A questo punto mi sono detto perché non supportare anche uno scenario di questo genere?:
[TestMethod]
[TestCategory( "AsyncWorker" ), TestCategory( "Threading" )]
public void asyncWorker_asAsyncAction_should_return_an_executable_asyncAction_with_support_for_triggers()
{
	var wa = new ManualResetEvent( false );
 
	var asyncAction = AsyncWorker.Using( 10 )
		.OnExecute( e =>
		{
			Thread.Sleep( 5 );
		} );
 
	IMonitor timerTrigger = new TimerTrigger( 5000, TriggerMode.Once );
	IExecutableWorker worker = asyncAction.AddTrigger( timerTrigger );
timerTrigger.NotifyChanged(); worker.Completed += ( s, e ) => { wa.Set(); }; var actual = wa.WaitOne( 10 ); actual.Should().Be.True(); }
Con quindi la possibilità di iniettare dei trigger, utilizzando la già nota interfaccia IMonitor, al fine di scatenare l’esecuzione.
Questa seconda funzionalità al momento non è ancora completa sto scrivendo i test e implementando un po’ di logica basata su WeakReference al fine di evitare “simpatici” leak.
.m