we use api
int getrusage(int who, struct rusage *usage); in Linux to calculate time in our code.
We use constant RUSAGE_THREAD as argument in this api for the calling thread.
As documented on the manual page RUSAGE_THREAD was introduced since Linux 2.6.26.
we also compile our code using cywin64 gcc4.8.2 in cygwin environment.
I have checked the header /usr/include/sys/resource.h in C:/cygwin64/
and I can't seem to find RUSAGE_THREAD defined there, it only has RUSAGE_SELF and RUSAGE_CHILDREN defined.
I am using cygwin64 (CYGWIN_NT-6.2 1.7.29(0.272/5/3) 2014-04-07 13:46 x86_64 Cygwin). I also tried to look into latest cygwin versions and can't seem to find it there as well.
So my question is, does cygwin support RUSAGE_THREAD ? If not then are there any plans to add this support ?
Thanks in advance.
It is not, mainly as it is not part of the POSIX standard
https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/sys_resource.h.html
The <sys/resource.h> header shall define the following symbolic
constants as possible values of the who parameter of getrusage():
RUSAGE_SELF
Returns information about the current process.
RUSAGE_CHILDREN
Returns information about children of the current process.
In general to add any functionality to Cygwin, two basic principles apply:
https://cygwin.com/acronyms/#SHTDI
https://cygwin.com/acronyms/#PTC
The cygwin and the cygwin-developers mailing list are good place to ask if you are planning to contribute
https://cygwin.com/lists.html
Related
I would like to provide individual names to the threads in my Rust program. These names should appear in top/htop so I can differentiate the thread's job. In Ruby I would modify the argv[0] entry, or maybe Process.setproctitle("foo"). My inspiration is from Ruby's Unicorn web server.
The env::args function returns an Args value. The Args value wraps the platform-specific std::sys::args::args() function which is not reexported for general use. ArgsOs doesn't have a usable mutator (so yes, the stdlib makes it clear it is immutable).
How do I mutate the arguments some other way? I am happy with a Linux-only solution since that is where the real work will happen. Solutions outside the stdlib are also fine.
What path should I take in order to modify the first argument in the environment of my process?
How can I replace an entry in std::env:args()
You cannot. Immutable means immutable.
I would like to change how my Rust program appears in top/htop
There is nothing like this in the standard library. As far as I know, there's no cross-platform solution, so it would be a hard fight to put in there.
Linux
Seems to have a simple enough solution: Change process name without changing argv[0] in Linux
If you only care about Linux, you can use the prctl crate:
prctl::set_name("new_process")
macOS
Has various concepts of "process name" and the solution is complex and uses undocumented / hidden APIs: Setting process name on Mac OS X at runtime
Everything in that answer could be written in Rust using the appropriate bindings to the macOS APIs.
Windows
Does not seem to have such a concept: Changing a process name in runtime
Cross-Platform
Someone could write a crate that abstracts across these different mechanisms, but I'm not aware of one.
so I can easily spot what all my threads are doing
As mentioned in the comments, when you create a thread, you can give it a name. Some work was recently put into renaming threads at run time, but that work stalled out.
I wrote the proctitle crate for setting process titles in a cross-platform manner. On Linux it does happen to name the current thread, but this is a quirk of the APIs it provides rather than a deliberate choice.
Let's say I want to use a specific Linux / POSIX feature, that is provided conditionally based on feature test macros. For example, the type cpu_set_t, the macro CPU_SET_ZERO, and the function sched_setaffinity.
Ideally I would just like to tell CMake that I need those, and it should figure out what extra feature test macros to set or fail with a nice error message if it can't be provided on the current system. Is that possible?
I am aware that I can lookup in the manpages and manually use add_definitions(-D_GNU_SOURCE), but that can become tedious once multiple functionalities that were introduced and deprecated in different versions of the POSIX standard are combined. In my experience, it can become difficult to maintain portability across different versions of the glibc implementation.
There are the CMake platform checks, but they only seem to help in checking. So I get the error during cmake rather than make, but I still have to figure out the right feature test macros manually.
cmake-compile-features seem to offer only features directly related to the compiler, not the library.
If you are just looking to determine whether a function or variable exists, you can use the CheckSymbolExists module. Likewise, there is CheckStructHasMember for structs (assuming there is a standard member you can check for). So:
include (CheckSymbolExists)
include (CheckStructHasMember)
CHECK_SYMBOL_EXISTS(CPU_SET_ZERO sched.h CPU_SET_ZERO_exists)
CHECK_SYMBOL_EXISTS(sched_setaffinity sched.h sched_setaffinity_exists)
CHECK_STRUCT_HAS_MEMBER(cpu_set_t <member?> sched.h cpu_set_t_exists)
It appears that cpu_set_t is an opaque type, so instead you can use the CheckCXXSourceCompiles module, which is a frontend for the try_compile command. It is a generic way to determine if any particular code compiles. try_compile is used extensively by 'base' CMake to determine features (try a search in the Modules directory!). Essentially, you pass it in a minimal source file, which should fail compilation if your feature is not present, and it reports back to your CMake script the result.
I have a driver that raises some warnings/errors during compilation, since the proc_fs api changed since its creation. The driver still uses create_proc_entry while the latest api version I am aware off, offers proc_create. Since I am new to driver programming under linux I tried to look at the source, however my ctags skills must be lacking since I only found proc_create in proc_fs.h. However, I would like to look at the implementation or some documentation, to know what error codes it returns so I know what I have to handle.
Can you point me to documentation for the proc api, or the source holding the definition of proc_create? A hint how it can be found would be appreciated as well.
create_proc is defined as an inline function, so it is fully implemented in the header proc_fs.h. It basically calls proc_create_data with a NULL for the data argument.
There seems very little documentation on these functions in the source so I'd recommend looking at other call sites within the kernel source, which you cam see listed in this LXR search.
BTW, creating new files in /proc seems frowned upon these days - it seems sysfs is where new interfaces should be created.
Best documentation for an API would be existing code itself. Check a few c files in fs/proc or grep for proc_create in the source code
sys/queue.h first appeared in 4.4BSD. Linux has included it in its distribution, but the version seems not up-to-date.
FreeBSD version implements singly-linked lists, singly-linked tail queues, lists and tail queues. Linux version implements lists, tail queues, and circular queues.
I installed libbsd-dev package in my Ubuntu PC and then found BSD version's sys/queue.h in /usr/include/bsd/sys/queue.h.
My questions:
Where can I find the Linux version of this header file?
What's the main difference between these two implementations? Is Linux version just a out-dated version of BSD's ?
They share the same ancestry, but it looks like any development that have been done in them diverged a long time ago.
If you want to use it in your project your best bet is to just copy the one you like the most into your project and use that. Don't depend on the system providing it for you. It's just a header file with a bunch of macros and doesn't need a library or any dependencies to work and as such isn't operating system specific at all. I usually take the one from OpenBSD for my projects.
Looks like Linux's version is seriously outdated. CIRCLEQ is (rather strongly) deprecated in BSDs since 2001, and it even got removed from the documentation, even if the implementation is still in queue.h. We are supposed to use TAILQ, which offers the same functionality with better performance/less problems/saner implementation.
Meanwhile, in Linux it's still even documented, but you can find changes in kconfig migrating from CIRCLEQ to TAILQ citing the BSD deprecation.
The concrete problem in CIRCLEQ seems to be that it uses a specific head, different to a list node, but which is anyway linked as a node; so the head pointer has to be kept around and checked at every node access to see if the node turns out to be the head. So there are 2 problems: the checks at every access, and the need to keep the head pointer at hand, taking registers or cache.
I have a C code which contains #include<synch.h> The code compiles successfully in solaris but in Linux I find that the header is missing.
As suggested in a few links, can "sync.h" be used instead?
Or is there any other equivalent header for synch.h in Linux?
The synch.h header in Solaris is for Solaris threads. Among other things, it provides declarations for semaphores and mutexes. You can either this library (http://sctl.sourceforge.net/sctl_v1.1_rn.html) to give you Solaris compatible threading on Linux or, a much better idea, rework your code to use POSIX threading.
We can't be sure, but one likely possibility is that this is the synch.h that's part of NACHOS, which is often used in educational environments. Head over to the NACHOS project page and read up on it, and decide whether you think that's probably the right thing; if so, you can download and install it for free.