This content has been marked as final. Show 3 replies
Questions about Solaris are best asked in a Solaris forum:
But in this case, you can find the answer from the fcntl man page:
The man page lists many attributes, and refers you to <fcntl.h>, which in turn includes <sys/fcntl.h>.
% man fnctl
I don't find any ASYNC options, so you will have to review the ones that are available to see which best fits yor needs.
That's basically just duplicating poll() functionality, with the benefit that the active file descriptor is identified in the siginfo_t structure. That functionality is provided in Solaris by using /dev/poll. See1 person found this helpful
Such functionality, where active file descriptors are identified directly, is needed to allow applications such as web servers and databases to scale to thousands and thousands of connections. Using the historical poll() interface, such an application would have to iterate through an array of perhaps 10,000 or more pollfd structures trying to find the active file descriptor(s) each and every time the poll() call detected an active file descriptor.
I know the /dev/poll device in Solaris was developed for just that purpose, and I strongly suspect the O_ASYNC/SIGIO functionality in Linux was created at least in part for that same reason - the scalability of applications handling a lot of connections.
As for your specific problem, if you're not using the information provided by the siginfo_t struction in your current Linux SIGIO handler, I think the simplest method to port your current functionality to Solaris would be to open /dev/poll, create a separate thread that performs the proper devpoll ioctl() on the open /dev/poll file descriptor, and self-signal when an active file descriptor is found, somthing like
where you'd replace SIGIO with your seleted Solaris signal. Then, where you'd open() (or otherwise obtain) and fcntl() your file descriptors in your Linux code, you'd just perform the approprate ioctls() in your /dev/poll file descriptor to add them to the poll set being used inside the kernel. Just be sure you also delete your file descriptors from that poll set right before you close them.
kill( getpid(), SIGIO )
If you're actually using the siginfo_t data in your current Linux SIGIO handler, your problem is probably harder, because offhand I can't recall any way for a userland process in Solaris to specify the contents of any signal's siginfo_t structure. If you can find a way to add an equivalent of the Linux SIGIO's siginfo_t to your selected Solaris signal, your problem is easy to solve - just create the /dev/poll polling thread like above and add the siginfo_t data. if you can't come up with a way to add the siginfo_t data with the active file descriptor, your problem could be a lot harder to solve depending on the design of your application.
Thank you for the detailed answer!
I'll try right away.