-
Notifications
You must be signed in to change notification settings - Fork 55
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Almost all threads are named "bees" now #51
Comments
Task creates its own threads and doesn't use BeesThread, so it doesn't set the BeesThread-specific variables. That said, Task could use Note that even if I fix this, it means most of the logs will end up with thread names like "worker_7", which is little more information than the tid in "pid.tid". The threads that remain will do only basic housekeeping. |
Well, so far that sounds like correct behavior. But in my logs I notice that the crawler no longer identifies itself as "crawl" but shows "bees" now. Was this intended? |
I haven't really thought about that much. Certainly the transition from a stateful-thread model (where each thread contains state, e.g. subvol crawl position) to a stateless-thread model (where a fixed number of threads execute self-contained tasks in dependency order) was intentional. The logging code is based on the earlier stateful-thread assumptions which are not so useful in a stateless-thread world. Task currently doesn't have a "name" field that we could write to the log (though we could add one).
I have a patch that logs |
Ah okay, now I start to understand the problem. The "stateless threads" was the missing key. Maybe the correct name could be pulled from the self contained task? I don't like the name worker neither. On the other hand, constantly changing how a thread id names itself in the log, could be confusing at best. Tho, it would make it more easy to extract, as an example, all crawler work from the logs... |
Well, we could leave the thread names alone (calling The Task names are things like "scan extent 0xf33234000" which could be useful to log (e.g. if there was an IO error, it would tell us the extent that was being processed at the time). On the other hand, I was planning to have Tasks with names like "dedup ..." (and the 3 lines of output that includes) and maybe we don't want to print those. Or on the gripping hand, the Task name could be "dedup 16K" and it could log the rest in only two lines, which would be a net improvement in many ways. |
At the first glance, I like the very last idea best. |
The master branch now writes the Task name on the log. Currently I made it look like the old subvol-threads output because the extent ref spec (BeesFileRange) was far too long. It will change over time as I get bees to be more extent-oriented instead of extent-ref oriented. Let me know what you think. |
To me it looks good currently. If you feel like closing this, proceed. |
Sometime after
v0.5
, probably during adding worker queues, all threads identify as "bees" which seems to come fromreturn "bees"
insrc/bees.cc
. This would mean that thread names are no longer set andtl_name
is just empty:During startup, it says that threads are created with their correct names but it's not picked up later during logging.
The text was updated successfully, but these errors were encountered: