From: "Network Nut" <sillystack@gmail.com>
To: <linux-kernel@vger.kernel.org>
Subject: WaitForMultipleObjects/etc. In Kernel
Date: Sat, 25 Jan 2014 16:01:53 -0600 [thread overview]
Message-ID: <00d901cf1a19$0ea62db0$2bf28910$@gmail.com> (raw)
Hi All,
This is my first post to anything Linux, so if there is a better mailing
list, please let me know.
I think that the facility by which a thread can block while waiting for any
of several synchronization primitives (*mutex*, *semaphore*, *event*,
*waitable
timer*)...is not only "nice to have", but fundamental to complex (clean)
multi-threaded programming. Of course, this facility is available on
Windows as *WaitForMultipleObjects *with all the associated functions.
That said, I have a C++ project on Windows that is nearly 100% portable.
The part that is not portable is mostly the synchronization elements. Every
year or so I take a cursory look at Linux's (Unix's) synchronization model,
and the process thread model, and...I guess you have heard it before - it's
simply not the same.
I have also seen various attempts on the web to create wrapper functions
that provide a Windows synchro API on Linux, but again, the result is never
quite the same. IBM, in their attempt and exposition, admits this. It is
clear, at least to me, that if one wants true ability to wait for any of
the various synchronization objects simultaneously, there needs to be
deliberate, explicit kernel support.
I was wondering:
1. What is the likelihood that the guardians of the kernel would even
allow something so fundamentally different inside?
2. My gut feeling is that adding such support would fundamentally change
other aspects of Linux. For example, I am vaguely familiar with asio, but
to do it the way it was done in Windows...
Finally, this is not a situation where the end-game is having a kernel of
my own that has such support. Support would need to be pre-existing for the
users of my project.
Please note that I am not a Windows bigot trying to impose a
Microsoft-centric world-view on Linux. I think this facility transcends any
particular OS, and I feel that it is merely fortunate coincidence that the
Microsoft (DEC) engineers had the inclination to do it.
-Nut
next reply other threads:[~2014-01-25 22:02 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-25 22:01 Network Nut [this message]
2014-01-26 18:33 ` WaitForMultipleObjects/etc. In Kernel Clemens Ladisch
2014-01-26 22:10 ` Network Nut
2014-01-27 9:06 ` Clemens Ladisch
2014-01-27 19:50 ` Network Nut
2014-01-28 9:04 ` Clemens Ladisch
2014-01-28 21:07 ` Network Nut
2014-01-29 8:30 ` Clemens Ladisch
2014-01-30 23:49 ` Network Nut
2014-01-31 17:05 ` Austin S. Hemmelgarn
2014-01-31 22:35 ` Network Nut
2014-01-31 22:53 ` Clemens Ladisch
2014-01-31 23:00 ` Network Nut
2014-01-31 23:08 ` Network Nut
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='00d901cf1a19$0ea62db0$2bf28910$@gmail.com' \
--to=sillystack@gmail.com \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox