Android：tgid task_struct val
我有一个守护进程，我不断启动并在循环中执行“kill -9”，以便对特定用例进行压力测试。该守护进程加载一个共享库，该库又打开一个文件描述符。 （fd的打开/关闭是在内核中处理的另一个共享库代码中）。我观察到，在内核库中进行清理操作时，它会在清理之前检查 task_structs (tgid) 中的 PID 值。 现在我的观察：我有时看到当守护进程被杀死时，我没有看到相关的 tgid 值，而是看到一个奇怪的进程 ID 值，该值是“binder 进程”。因此，我在内核代码中的清理操作不会对被“kill -9”杀死的进程 ID 生效
。任何人都知道为什么 current->tgid 值是活页夹进程的值，而不是绑定进程的值。被杀死的守护进程。请注意，我的守护进程确实链接到“libbinder”。不确定这是否会有所作为。如果我从我的守护进程中删除到“libbinder”及其相关代码的链接，一切看起来都很好
请问有什么建议/想法吗？
I have a daemon that I continuously start and do a 'kill -9' in a loop in order to stress test a particular use case. This daemon loads a shared library which in turn opens a fd. (opening / closing of fd is in another shared library code handled in kernel) . I observe that at the time of clean up operations in the kernel library, it checks for the PID value from task_structs, (tgid) before cleaning up .
Now my observation : I sometime see that when the daemon gets killed , i do not see a relevant tgid value instead i see a strange process ID value which of 'binder process'. As a result my clean up operations in the kernel code does not take in effect for that process ID that juts got killed by 'kill -9'
Any one knows why current->tgid value is that of a binder process and not of the daemon that gets killed. Note that my daemon does link to 'libbinder'. Not sure if that can make a difference. If I remove the linking to 'libbinder' and its relevant code from my daemon, everything seems fine
Any suggestions/ ideas please?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
如果您的用户空间进程打开一个文件，然后分叉另一个进程，则打开的文件将在分叉的进程中重复（看来这个 libbinder 可能正在分叉另一个进程）。
仅当放置对文件的last引用时，才会调用内核中
file_operations结构的close方法。如果两个进程大约在同一时间死亡，那么最终调用 close 方法的进程将是第二个死亡的进程。您的内核代码不应该键入
tgid。它应该将清理操作所需的数据附加到struct file，而不是附加到task_struct。If your userspace process opens a file, then forks another process, the open file will be duplicated in the forked process (it appears probable that this
libbinderis forking off another process).The close method of the
file_operationsstruct in the kernel will only be called when the last reference to the file is put. If both processes die around the same time, then the process which ends up calling the close method will be whichever one happens to die second.Your kernel code should not be keying on
tgid. It should be attaching the data required for the cleanup operations to thestruct file, not to thetask_struct.