Architecture best practices

[Chrisa23]

Obviously Retlang is ideal for a Pipes and Filters type architecture,
and some of my code is architected this way.

I have tried a variety of ways of working with Retlang, and wanted to
discuss some of them and their pros and cons, and any potential issues
or bad practices I might not be aware of.

Early on in my Retlang experimentation I was implementing things as
components with a ThreadFiber that would pass its fiber to children
objects. I didn't run into any issues in doing this, and in my mind,
I was controlling the number of threads in the application and
insuring the types of work they did. Plus there was the benefit of my
internal structures for components could utilize Retlang's messaging
paradigm and get rid of .Net events. This never felt correct though.

I stopped structuring things in this way, but have been pondering what
is ideal for what I am trying to do.

I know I had a misunderstanding of the PoolFiber, and was under the
assumption that sequential-ness was lost and Actions were just
immediately queued to the pool. I understand now, that PoolFibers act
much more like a ThreadFiber with an indeterminate thread but
guaranteed sequentiality.

The current way I am using Retlang in my project is with lots and lots
of threads... I am building an algorithmic trading system as a
personal project, and currently I have a structure where my main
control class has one thread, and each of my market watching signals
have a thread and every trade that is placed has its own thread...
That can be a lot of threads... I figure the PoolFiber might be the
correct alternative to what I am doing to limit the total number of
threads running in the app, but I also think there are some other
alternatives I have not realized yet and I'm not sure having hundreds
of threads is problematic...

I haven't ran into any issues using either design, but I have
definitely wanted to discuss things with others to get some outside
perspective and hopefully share in the benefit of other's
experience...

[Mike Rettig]

I communicate across fibers via channels. This allows components to be
developed in isolation. Fibers do not have access to other fibers,
only channels. A component is single threaded and responds to
sequential events that arrive via channels. The component can publish
new events via channels or via TCP, UDP, JMS, etc.

I also prefer fewer fibers than many but it depends on your
application. Pool fibers work well for many threads, but it depends on
what you mean by many. The OS is very good at context switching and
can easily handle tens or hundreds of threads. You should do some
benchmarks with your application to see if the pool or dedicated
threads work better. Retlang should make the switch transparent if you
code to the Fiber interface.

Mike

> --
> You received this message because you are subscribed to the Google Groups "retlang-dev" group.
> To post to this group, send email to retla...@googlegroups.com.
> To unsubscribe from this group, send email to retlang-dev...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/retlang-dev?hl=en.
>
>

[Chrisa23]

Thanks for your clarification on usage... I have been looking at the
Integration Patterns book for ideas on messaging architecture as
well... I was not familiar with messaging prior to using Retlang...

I have been strictly one fiber per component for a while, but I have
found myself in some sticky spots where I thought about doing things
in the way I first approached Retlang... For the most part I have
embraced the fact that I most likely need to rethink my architecture
rather than resort to re-using threads...

Chris