c - C 中的数据流库

Question

如何在 C 中进行数据流(管道和过滤器、流处理、基于流)？而不是 UNIX 管道。

我最近遇到了 stream.py .

Streams are iterables with a pipelining mechanism to enable data-flow programming and easy parallelization.

The idea is to take the output of a function that turns an iterable into another iterable and plug that as the input of another such function. While you can already do this using function composition, this package provides an elegant notation for it by overloading the >> operator.

我想在 C 中复制这种功能的简单版本。我特别喜欢重载 >>> 运算符以避免函数组合困惑。维基百科指向 this hint摘自 1990 年的 Usenet 帖子。

为什么选择 C？因为我希望能够在微 Controller 和其他高级语言(Max、Pd*、Python)的 C 扩展中执行此操作。

*(具有讽刺意味的是，Max 和 Pd 是用 C 语言编写的，专门用于此目的——我正在寻找准系统)

Answer 1

我知道，这不是一个好的答案，但您应该制作自己的简单数据流框架。

我(和我的一个 friend 一起)写了一个原型(prototype) DF 服务器，它有几个未实现的功能:它只能在消息中传递 Integer 和 Trigger 数据，并且它不支持并行。我刚刚跳过了这项工作:组件的生产者端口有一个指向消费者端口的函数指针列表，这些函数指针在初始化时设置，并且他们调用它(如果列表不为空)。因此，当事件触发时，组件会执行数据流图的树状遍历。当他们使用整数和触发器时，速度非常快。

另外，我写了一个奇怪的组件，它有一个消费者端口和一个生产者端口，它只是简单地传递数据 - 但在另一个线程中。它的消费者例程很快完成，因为它只是将数据放入生产者端线程并设置一个标志。很脏，但它符合我的需要:它分离了树木行走的漫长过程。

因此，正如您可能认识到的那样，它是一个用于快速任务的低流量异步系统，其中图形大小无关紧要。

不幸的是，您的问题与我的问题有很多不同点，就像一个数据流系统可能与另一个数据流系统不同一样，您需要一个同步的、并行的、流处理的解决方案。

我认为，DF 服务器中最大的问题是调度程序。并发、冲突、线程、优先级……正如我所说，我只是跳过了问题，没有解决。你也应该跳过它。你也应该跳过其他问题。

调度员

在同步 DF 架构的情况下，所有组件必须每个周期运行一次，特殊情况除外。他们有一个简单的先决条件:输入数据是否可用？因此，您应该只扫描组件，并将它们传递给一个空闲的调用线程(如果数据可用)。处理完所有这些后，您将有 N 个未处理的剩余组件。您应该再次处理该列表。第二次处理后，您将剩下 M 个。如果N == M，则循环结束。

我认为如果组件的数量少于 100，一些相同的东西会起作用。

绑定(bind)

是的，最好的绑定(bind)方式是可视化编程。在完成编辑器之前，类似配置的代码应该使用 insetad，例如:

 // disclaimer: not actual code
 Component* c1 = new AddComponent();
 Component* c2 = new PrintComponent();
 c2->format = "The result is %d\n";
 bind(c1->result,c2->feed);

写起来容易，可读性好，其他愿望？

留言

您应该在组件的端口之间传递纯原始数据包。您只需要一个绑定(bind)列表，其中包含成对的生产者端口和消费者端口指针，并包含“调度程序”使用的已处理标志。

调用问题

问题是生产者不应该调用消费者端口，而是组件；所有组件(类)变量和触发都在组件中。因此，生产者应该直接调用组件的公共(public)入口点，将消费者的 ID 传递给它，或者它应该调用端口，它应该调用它所属组件的任何方法。

---

所以，如果你能忍受一些限制，我说，继续吧，写你的精简版框架。这是一项很好的任务，但是编写小组件并看看它们如何智能地连接在一起构建一个伟大的应用程序才是终极乐趣。

如果你有更多问题，尽管问，我经常在这里扫描“数据流”关键字。

可能，您可以为您的程序找出一个更简单的数据流模型。