使用 numpy.memmap 映射设备文件

发布于 2024-10-17 01:12:17 字数 667 浏览 2 评论 0原文

使用 numpy 的 memmap 打开设备文件（而不是常规文件）是否有原因？

self.surface = np.memmap('/dev/fb1', dtype=np.uint16, mode='r+', shape=(320,240))

我正在使用一个自定义内核模块，该模块添加了一个帧缓冲区设备，它与 python 的常规 mmap 模块配合得很好。但是使用 numpy 似乎会在访问文件系统或其他东西时挂起内核的互斥体（我真的不确定到底发生了什么）。

我的问题是 numpy 的 memmap 无法处理，我应该采取不同的方式吗？

我在 unix stackexchange 上问了另一个问题，但我觉得这是两个不同的问题，所以我两者都已发布。

显然这是在 Linux 上（带有自定义内核模块的 kubuntu maverick）

更新：

好吧，事实证明我可以很好地创建内存映射。问题似乎是，当我关闭进程而不专门关闭 memmap 对象时，它只会挂在内核中的互斥锁上。

我不知道这个问题是否与 numpy、我的内核模块或其他地方有关。

原文

Is there a reason that opening a device file (rather than a regular file) using numpy's memmap shouldn't work?

self.surface = np.memmap('/dev/fb1', dtype=np.uint16, mode='r+', shape=(320,240))

I'm working with a custom kernel module that adds a framebuffer device, which works fine with python's regular mmap module. But using numpy seems to hang the kernel's mutex on accessing the filesystem or something (I'm really not sure exactly what's happening).

My question here is specifically is this something that numpy's memmap can't handle and I should go a different way?

I've asked another question on unix stackexchange, but I feel like it's 2 different questions so I've posted them both.

Obviously this is on linux (kubuntu maverick with custom kernel module)

Update:

Well, it turns out I can create the memmap fine. The problem it seems is that when I close the process without specifically closing the memmap object and it will just hang on the mutex in the kernel.

I have no idea if this issue is with numpy, or my kernel module, or somewhere else.

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

南渊 2024-10-24 01:12:17

如果您的代码与 python mmap 模块配合良好，您可以直接使用它而不是 numpy.memmap：

>>> fd = os.open("a", os.O_RDWR)
>>> buffer = mmap.mmap(fd, 0)
>>> surface = np.ndarray((320,240), np.uint16, buffer)

这还有另一个优点，即您可以更好地控制内存映射用过的。

现在，Python 的 mmap 有其自身的特点。正如源所示，它调用msync 取消分配。也许这就是你的程序挂起的地方？（您也许可以使用 buffer.flush() 重现您的问题，它也调用 msync）。您首先调用 close() 的解决方案可能有效，因为它绕过了 msync！

If your code works fine with the python mmap module, you can use it directly instead of numpy.memmap:

>>> fd = os.open("a", os.O_RDWR)
>>> buffer = mmap.mmap(fd, 0)
>>> surface = np.ndarray((320,240), np.uint16, buffer)

This has the other advantage that you have more control over the memory mapping used.

Now, python's mmap has its own peculiarities. As the source shows, it calls msync on delallocation. Maybe this is where your program hangs? (You might be able to reproduce your issue with buffer.flush(), which also calls msync). Your solution of calling close() first probably works because it circumvents msync!

回复收藏 0 原文

~没有更多了~