Fri Nov 17 12:29:20 2017
EVENTS
 FREE
SOFTWARE
INSTITUTE

POLITICS
JOBS
MEMBERS'
CORNER

MAILING
LIST

NYLXS Mailing Lists and Archives
NYLXS Members have a lot to say and share but we don't keep many secrets. Join the Hangout Mailing List and say your peice.

DATE 2015-05-01

HANGOUT

2017-11-17 | 2017-10-17 | 2017-09-17 | 2017-08-17 | 2017-07-17 | 2017-06-17 | 2017-05-17 | 2017-04-17 | 2017-03-17 | 2017-02-17 | 2017-01-17 | 2016-12-17 | 2016-11-17 | 2016-10-17 | 2016-09-17 | 2016-08-17 | 2016-07-17 | 2016-06-17 | 2016-05-17 | 2016-04-17 | 2016-03-17 | 2016-02-17 | 2016-01-17 | 2015-12-17 | 2015-11-17 | 2015-10-17 | 2015-09-17 | 2015-08-17 | 2015-07-17 | 2015-06-17 | 2015-05-17 | 2015-04-17 | 2015-03-17 | 2015-02-17 | 2015-01-17 | 2014-12-17 | 2014-11-17 | 2014-10-17 | 2014-09-17 | 2014-08-17 | 2014-07-17 | 2014-06-17 | 2014-05-17 | 2014-04-17 | 2014-03-17 | 2014-02-17 | 2014-01-17 | 2013-12-17 | 2013-11-17 | 2013-10-17 | 2013-09-17 | 2013-08-17 | 2013-07-17 | 2013-06-17 | 2013-05-17 | 2013-04-17 | 2013-03-17 | 2013-02-17 | 2013-01-17 | 2012-12-17 | 2012-11-17 | 2012-10-17 | 2012-09-17 | 2012-08-17 | 2012-07-17 | 2012-06-17 | 2012-05-17 | 2012-04-17 | 2012-03-17 | 2012-02-17 | 2012-01-17 | 2011-12-17 | 2011-11-17 | 2011-10-17 | 2011-09-17 | 2011-08-17 | 2011-07-17 | 2011-06-17 | 2011-05-17 | 2011-04-17 | 2011-03-17 | 2011-02-17 | 2011-01-17 | 2010-12-17 | 2010-11-17 | 2010-10-17 | 2010-09-17 | 2010-08-17 | 2010-07-17 | 2010-06-17 | 2010-05-17 | 2010-04-17 | 2010-03-17 | 2010-02-17 | 2010-01-17 | 2009-12-17 | 2009-11-17 | 2009-10-17 | 2009-09-17 | 2009-08-17 | 2009-07-17 | 2009-06-17 | 2009-05-17 | 2009-04-17 | 2009-03-17 | 2009-02-17 | 2009-01-17 | 2008-12-17 | 2008-11-17 | 2008-10-17 | 2008-09-17 | 2008-08-17 | 2008-07-17 | 2008-06-17 | 2008-05-17 | 2008-04-17 | 2008-03-17 | 2008-02-17 | 2008-01-17 | 2007-12-17 | 2007-11-17 | 2007-10-17 | 2007-09-17 | 2007-08-17 | 2007-07-17 | 2007-06-17 | 2007-05-17 | 2007-04-17 | 2007-03-17 | 2007-02-17 | 2007-01-17 | 2006-12-17 | 2006-11-17 | 2006-10-17 | 2006-09-17 | 2006-08-17 | 2006-07-17 | 2006-06-17 | 2006-05-17 | 2006-04-17 | 2006-03-17 | 2006-02-17 | 2006-01-17 | 2005-12-17 | 2005-11-17 | 2005-10-17 | 2005-09-17 | 2005-08-17 | 2005-07-17 | 2005-06-17 | 2005-05-17 | 2005-04-17 | 2005-03-17 | 2005-02-17 | 2005-01-17 | 2004-12-17 | 2004-11-17 | 2004-10-17 | 2004-09-17 | 2004-08-17 | 2004-07-17 | 2004-06-17 | 2004-05-17 | 2004-04-17 | 2004-03-17 | 2004-02-17 | 2004-01-17 | 2003-12-17 | 2003-11-17 | 2003-10-17 | 2003-09-17 | 2003-08-17 | 2003-07-17 | 2003-06-17 | 2003-05-17 | 2003-04-17 | 2003-03-17 | 2003-02-17 | 2003-01-17 | 2002-12-17 | 2002-11-17 | 2002-10-17 | 2002-09-17 | 2002-08-17 | 2002-07-17 | 2002-06-17 | 2002-05-17 | 2002-04-17 | 2002-03-17 | 2002-02-17 | 2002-01-17 | 2001-12-17 | 2001-11-17 | 2001-10-17 | 2001-09-17 | 2001-08-17 | 2001-07-17 | 2001-06-17 | 2001-05-17 | 2001-04-17 | 2001-03-17 | 2001-02-17 | 2001-01-17 | 2000-12-17 | 2000-11-17 | 2000-10-17 | 2000-09-17 | 2000-08-17 | 2000-07-17 | 2000-06-17 | 2000-05-17 | 2000-04-17 | 2000-03-17 | 2000-02-17 | 2000-01-17 | 1999-12-17

Key: archive Value: 2015-05-01

Key: id Value: 543312

MESSAGE
DATE 2015-05-04
FROM Ruben Safir
SUBJECT Subject: [NYLXS - HANGOUT] Fwd: Kernel Scheduling and wait queues
From owner-hangout-outgoing-at-mrbrklyn.com Mon May 4 03:05:30 2015
Return-Path:
X-Original-To: archive-at-mrbrklyn.com
Delivered-To: archive-at-mrbrklyn.com
Received: by mrbrklyn.com (Postfix)
id 65D381612EC; Mon, 4 May 2015 03:05:30 -0400 (EDT)
Delivered-To: hangout-outgoing-at-mrbrklyn.com
Received: by mrbrklyn.com (Postfix, from userid 28)
id 5676D1612EE; Mon, 4 May 2015 03:05:30 -0400 (EDT)
Delivered-To: hangout-at-nylxs.com
Received: from mailbackend.panix.com (mailbackend.panix.com [166.84.1.89])
by mrbrklyn.com (Postfix) with ESMTP id 7C4451612EC
for ; Mon, 4 May 2015 03:05:06 -0400 (EDT)
Received: from [10.0.0.19] (www.mrbrklyn.com [96.57.23.82])
by mailbackend.panix.com (Postfix) with ESMTPSA id 38016122AA
for ; Mon, 4 May 2015 03:05:06 -0400 (EDT)
Message-ID: <55471A21.1040802-at-panix.com>
Date: Mon, 04 May 2015 03:05:05 -0400
From: Ruben Safir
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: hangout
Subject: [NYLXS - HANGOUT] Fwd: Kernel Scheduling and wait queues
References: <20150422091305.302-at-kylheku.com> <87sibsays5.fsf-at-doppelsaurus.mobileactivedefense.com> <20150422110344.469-at-kylheku.com> <20150422160337.511-at-kylheku.com>
In-Reply-To: <20150422160337.511-at-kylheku.com>
X-Forwarded-Message-Id: <20150422091305.302-at-kylheku.com> <87sibsays5.fsf-at-doppelsaurus.mobileactivedefense.com> <20150422110344.469-at-kylheku.com> <20150422160337.511-at-kylheku.com>
Content-Type: multipart/mixed;
boundary="------------010208080807060702010400"
Sender: owner-hangout-at-mrbrklyn.com
Precedence: bulk
Reply-To: hangout-at-nylxs.com
[NYLXS: HANGOUT]
X-BeenThere: hangout-at-nylxs.com
X-Mailing-list: hangout-at-nylxs.com
Precedence: list
List-Id: NYLXS General Discussion Forum
List-Unsubscribe:
List-Archive:
List-Post:
List-Help:
List-Subscribe:


This is a multi-part message in MIME format.
--------------010208080807060702010400
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


--------------010208080807060702010400
Content-Type: message/rfc822;
name="Kernel Scheduling and wait queues.eml"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename="Kernel Scheduling and wait queues.eml"

Path: reader1.panix.com!panix!not-for-mail
From: ruben safir
Newsgroups: comp.unix.programmer
Subject: Kernel Scheduling and wait queues
Date: Wed, 22 Apr 2015 08:21:24 -0400
Organization: PANIX Public Access Internet and UNIX, NYC
Message-ID:
NNTP-Posting-Host: www.mrbrklyn.com
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
X-Trace: reader1.panix.com 1429705284 12103 96.57.23.82 (22 Apr 2015 12:21:24 GMT)
X-Complaints-To: abuse-at-panix.com
NNTP-Posting-Date: Wed, 22 Apr 2015 12:21:24 +0000 (UTC)
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0
Xref: panix comp.unix.programmer:234521


I'm just posting this because I'm hoping I can get some insight from the
advanced coders here...

thanx

Ruben
~~~~~~~~~~~~~~~~~~~

Ruben QUOTED Previously:

<<Chapter 4 on the wait queue how it is implemented in the text
completely surprised me.

He is recommending that you have to write your own wait queue entry
routine for every process? Isn't that reckless?

He is suggesting

DEFINE_WAIT(wait) //what IS wait EXACTLY in this context

add_wait_queue(q, &wait); // in the current kernel this invovled
// flag checking and a linked list

while(!condition){ /* an event we are weighting for
prepare_to_wait(&q, &wait, TASK_INTERRUPTIBLE);
if(signal_pending(current))
/* SIGNAl HANDLE */
schedule();
}

finish_wait(&q, &wait);

He also write how this proceeds to function and one part confuses me

5. When the taks awakens, it again checks whether the condition is
true. If it is, it exists the loop. Otherwise it again calls schedule.


This is not the order that it seems to follow according to the code.

To me it looks like it should
1 - creat2 the wait queue
2 - adds &wait onto queue q
3 checks if condition is true, if so, if not, enter a while loop
4 prepare_to_wait which changes the status of our &wait to
TASK_INTERUPPABLE
5 check for signals ... notice the process is still moving. Does it
stop and wait now?
6 schedule itself on the runtime rbtree... which make NO sense unless
there was a stopage I didn't know about.
7 check the condition again and repeat while look
7a. if the loop ends fishish_waiting... take it off the queue.



Isn't this reckless to leave this to users to write the code. Your
begging for a race condition.

Ruben >>



On 04/21/2015 11:05 AM, michi1-at-michaelblizek.twilightparadox.com wrote:
> Hi!
>
> On 12:39 Mon 20 Apr , Ruben Safir wrote:
>> On 04/20/2015 11:23 AM, michi1-at-michaelblizek.twilightparadox.com wrote:
>>> I would not recommend that. There are already functions in
linux/wait.h for
>>> these purposes like wait_event_interruptible().
>>
>>
>> can you do that in the kernel? The wait_event_interuptable creates wait
>> queues?
>
> No, wait_event_interuptable waits on an existing waitqueue. If you want to
> create a waitqueue, call init_waitqueue_head().
>
> -Michi
>


Here is the confusing part. this is a discussion on wait and semiphores
in a standard text

5.6.2
Semaphore Implementation
Recall that the implementation of mutex locks discussed in Section 5.5
suffers from busy waiting. The definitions of the wait() and signal()
semaphore operations just described present the same problem. To
overcome the need for busy waiting, we can modify the definition of the
wait() and signal() operations as follows: When a process executes the
wait() operation and finds that the semaphore value is not positive, it
must wait. However, rather than engaging in busy waiting, the process
can block itself. The block operation places a process into a waiting
queue associated with the semaphore, and the state of the process is
switched to the waiting state. Then control is transferred to the CPU
scheduler, which selects another process to execute.

A process that is blocked, waiting on a semaphore S, should be restarted
when some other process executes a signal() operation. The process is
restarted by a wakeup() operation, which changes the process from the
waiting state to the ready state. The process is then placed in the
ready queue. (The CPU may or may not be switched from the running
process to the newly ready process, depending on the CPU-scheduling
algorithm.)

To implement semaphores under this definition, we define a semaphore as
follows:

typedef struct {
int value;
struct process *list;
} semaphore;

Each semaphore has an integer value and a list of processes list. When
a process must wait on a semaphore, it is added to the list of processes. A
signal() operation removes one process from the list of waiting
processes and awakens that process.
Now, the wait() semaphore operation can be defined as

wait(semaphore *S) {
S->value--;
if (S->value < 0) {
add this process to S->list;
block();
}
}

and the signal() semaphore operation can be defined as

signal(semaphore *S) {
S->value++;
if (S->value <= 0) {
remove a process P from S->list;
wakeup(P);
}
}


Minus the Semiphore, that sounds like what we are doing with the wait
list in the scheduler. But it looks like we are leaving it to the
user. Why? It is similar but oddly different so I'm trying to figure
out what is happening here.

Ruben


_______________________________________________
Kernelnewbies mailing list
Kernelnewbies-at-kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies



--------------010208080807060702010400
Content-Type: message/rfc822;
name="Re: Kernel Scheduler and wiat queues.eml"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename="Re: Kernel Scheduler and wiat queues.eml"

Path: reader1.panix.com!panix!goblin3!goblin2!goblin.stu.neva.ru!aioe.org!.POSTED!not-for-mail
From: Kaz Kylheku
Newsgroups: comp.unix.programmer
Subject: Re: Kernel Scheduler and wiat queues
Date: Wed, 22 Apr 2015 16:31:25 +0000 (UTC)
Organization: Aioe.org NNTP Server
Message-ID: <20150422091305.302-at-kylheku.com>
References:
NNTP-Posting-Host: OGJi3KNpFOhM58UHZwXj0w.user.speranza.aioe.org
X-Complaints-To: abuse-at-aioe.org
User-Agent: slrn/pre1.0.0-18 (Linux)
X-Notice: Filtered by postfilter v. 0.8.2
Xref: panix comp.unix.programmer:234522

On 2015-04-22, ruben safir wrote:
> DEFINE_WAIT(wait) //what IS wait EXACTLY in this context

A preprocessor token, used as the argument to a macro call.

To understand what it means, you must look at the macro expansion.

What the macro does is generate code to define a variable whose name is "wait".
It is abstracted away because, possibly, the variable is not only defined, but
requires initialization. It requires initialization in ways that could change
as the kernel is maintained, so it needs to be abstract.

> add_wait_queue(q, &wait); // in the current kernel this invovled
> // flag checking and a linked list
>
> while(!condition){ /* an event we are weighting for
> prepare_to_wait(&q, &wait, TASK_INTERRUPTIBLE);
> if(signal_pending(current))
> /* SIGNAl HANDLE */
> schedule();
> }
>
> finish_wait(&q, &wait);
>
> He also write how this proceeds to function and one part confuses me
>
> 5. When the taks awakens, it again checks whether the condition is
> true. If it is, it exists the loop. Otherwise it again calls schedule.

This is just the consequence of the code you have before you. When
the task awakens it returns out of the schedule() call, and continues
with the loop.

> This is not the order that it seems to follow according to the code.
>
> To me it looks like it should
> 1 - creat2 the wait queue

You really mean "wait queue node". The wait queue already exists, but
the task needs a queuing data structure so that it can add itself to
that queue.

(Why does a task need an extra structure for this rather than just some
link pointers inside its task structure. The answer is that a task
can wait on multiple wait queues queues at the same time:

DEFINE_WAIT(node0);
DEFINE_WAIT(node1);
/* ... */
DEFINE_WAIT(nodeN);

add_wait_queue(q0, &node0);
add_wait_queue(q1, &node1);
/* ... */
add_wait_queue(q1, &nodeN);

while (!condition) {
prepare_to_wait(&q0, &node0, TASK_INTERRUPTIBLE);
prepare_to_wait(&q1, &node1, TASK_INTERRUPTIBLE);
/* ... */
prepare_to_wait(&qn, &nodeN, TASK_INTERRUPTIBLE);

if(signal_pending(current)) { /* SIGNAl HANDLE */ }

schedule();
}

finish_wait(&q0, &node0);
finish_wait(&q1, &node1);
/* ... */
finish_wait(&qn, &nodeN);

> 5 check for signals ... notice the process is still moving. Does it
> stop and wait now?

No, it stops and waits somewhere inside the schedule() function, and only
there. Elsewhere, the code is running.

> 6 schedule itself on the runtime rbtree... which make NO sense unless
> there was a stopage I didn't know about.

It makes perfect sense. The task changes its status to "interruptible sleep",
and then informs the scheduler, by calling the schedule() function.
The scheduler puts that into effect, and removes the task from the run queue.
Then it makes a scheduling decision to dispatch a task. The task which
called it is not eligible for execution now, so another task is chosen.

> Isn't this reckless to leave this to users to write the code. Your
> begging for a race condition.

Yes, of course you are absolutely right; most kernel developers should not be
writing the above open code most of the time. The best justification for
it is that you're developing a new synchronization primitive (which itself
requires justification as to why the existing ones aren't good enough).

There are higher level primitives which wrap the above logic: semaphores,
read-write semaphores, mutexes, events, poll, ...

For instance, look for wait_event, wait_event_interruptible, and related
macros.

--------------010208080807060702010400
Content-Type: message/rfc822;
name="Re: Kernel Scheduler and wiat queues.eml"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename="Re: Kernel Scheduler and wiat queues.eml"

Path: reader1.panix.com!panix!goblin3!goblin.stu.neva.ru!bolzen.all.de!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail
From: Rainer Weikusat
Newsgroups: comp.unix.programmer
Subject: Re: Kernel Scheduler and wiat queues
Date: Wed, 22 Apr 2015 17:55:06 +0100
Message-ID: <87sibsays5.fsf-at-doppelsaurus.mobileactivedefense.com>
References: <20150422091305.302-at-kylheku.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Trace: individual.net HNSRaNth1zP/WQ5XpOOARwUPhN6pW+FgmsMxAm7H/2tNPOD+k=
Cancel-Lock: sha1:1KB3kgqkkr0Bkv0gGl9sQmE8FnE= sha1:+g4tgBpuw3aST93HN5A71CajRIA=
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux)
Xref: panix comp.unix.programmer:234523

Kaz Kylheku writes:
> On 2015-04-22, ruben safir wrote:

[...]

>> 6 schedule itself on the runtime rbtree... which make NO sense unless
>> there was a stopage I didn't know about.
>
> It makes perfect sense. The task changes its status to "interruptible sleep",
> and then informs the scheduler, by calling the schedule() function.
> The scheduler puts that into effect, and removes the task from the run
> queue.

schedule() is the top-level entry point of the scheduler, so, a more
accurate description would be "it calls into the scheduler in order to
make that select some task to run". Maybe a higher priority task than
the one which called schedule is runnable. In this case, the higher
priority task will run instead of the one which called
schedule. Otherwise, this task will continue to run unless it changed
its state to something other than 'runnable' first.

>> Isn't this reckless to leave this to users to write the code. Your
>> begging for a race condition.
>
> Yes, of course you are absolutely right; most kernel developers should not be
> writing the above open code most of the time. The best justification for
> it is that you're developing a new synchronization primitive (which itself
> requires justification as to why the existing ones aren't good
> enough).

I completely disagree with this: Just because more or less useful and
more or less buggy of bug-free 'special-case wait for this, that or
something else' code keeps piling up in in include/linux/wait.h doesn't
mean anyone ought to be required to read through all of this whenever
some kernel code has to wait for something to select the currently least
worse bit of infrastructure code from there, considering that the simple
solution of just coding the wait loop will work for every situation and
is all over the kernel for historical reasons, anyway.

Some people can't ever do anything without producing a "general purpose
library" (or a couple of these) [or can't ever do anything except
that]. Considering this obvious lack of practically applicable skills,
no code deserves to be used just because someone wrote it.


--------------010208080807060702010400
Content-Type: message/rfc822;
name="Re: Kernel Scheduler and wiat queues.eml"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename="Re: Kernel Scheduler and wiat queues.eml"

Path: reader1.panix.com!panix!goblin2!goblin.stu.neva.ru!aioe.org!.POSTED!not-for-mail
From: Kaz Kylheku
Newsgroups: comp.unix.programmer
Subject: Re: Kernel Scheduler and wiat queues
Date: Wed, 22 Apr 2015 18:20:48 +0000 (UTC)
Organization: Aioe.org NNTP Server
Message-ID: <20150422110344.469-at-kylheku.com>
References:
<20150422091305.302-at-kylheku.com>
<87sibsays5.fsf-at-doppelsaurus.mobileactivedefense.com>
NNTP-Posting-Host: OGJi3KNpFOhM58UHZwXj0w.user.speranza.aioe.org
X-Complaints-To: abuse-at-aioe.org
User-Agent: slrn/pre1.0.0-18 (Linux)
X-Notice: Filtered by postfilter v. 0.8.2
Xref: panix comp.unix.programmer:234524

On 2015-04-22, Rainer Weikusat wrote:
> Kaz Kylheku writes:
>> On 2015-04-22, ruben safir wrote:
>>> Isn't this reckless to leave this to users to write the code. Your
>>> begging for a race condition.
>>
>> Yes, of course you are absolutely right; most kernel developers should not be
>> writing the above open code most of the time. The best justification for
>> it is that you're developing a new synchronization primitive (which itself
>> requires justification as to why the existing ones aren't good
>> enough).
>
> I completely disagree with this: Just because more or less useful and
> more or less buggy of bug-free 'special-case wait for this, that or
> something else' code keeps piling up in in include/linux/wait.h doesn't
> mean anyone ought to be required to read through all of this whenever
> some kernel code has to wait for something to select the currently least
> worse bit of infrastructure code from there, considering that the simple
> solution of just coding the wait loop will work for every situation and
> is all over the kernel for historical reasons, anyway.

I'm the opposite. Give me a large number of primitives to choose from!

By the way, I used mutexes and condition variables in the kernel back in 1998,
before any such a thing existed in the kernel, and made a little package of
that. It supported a driver I was working on:

http://www.kylheku.com/~kaz/lmc.html

A few years ago, on another job, I also wrote a "super poll function".
With this bugger, you could, simultaneously:

- wait on a set of sockets (struct socket *)
- wait on a set of files (struct file *)
- wait on a condition variable
- with a timeout

with this mega-function, I multiplexed a ton of functionality onto a single
kernel thread.

--------------010208080807060702010400
Content-Type: message/rfc822;
name="Re: Kernel Scheduler and wiat queues.eml"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename="Re: Kernel Scheduler and wiat queues.eml"

Path: reader1.panix.com!panix!goblin3!goblin2!goblin.stu.neva.ru!feeder.erje.net!1.eu.feeder.erje.net!news2.arglkargh.de!news.mixmin.net!aioe.org!.POSTED!not-for-mail
From: Kaz Kylheku
Newsgroups: comp.unix.programmer
Subject: Re: Kernel Scheduler and wiat queues
Date: Wed, 22 Apr 2015 23:04:32 +0000 (UTC)
Organization: Aioe.org NNTP Server
Message-ID: <20150422160337.511-at-kylheku.com>
References:
<20150422091305.302-at-kylheku.com>
<87sibsays5.fsf-at-doppelsaurus.mobileactivedefense.com>
<20150422110344.469-at-kylheku.com>
NNTP-Posting-Host: OGJi3KNpFOhM58UHZwXj0w.user.speranza.aioe.org
X-Complaints-To: abuse-at-aioe.org
User-Agent: slrn/pre1.0.0-18 (Linux)
X-Notice: Filtered by postfilter v. 0.8.2
Xref: panix comp.unix.programmer:234525

On 2015-04-22, Kaz Kylheku wrote:
> By the way, I used mutexes and condition variables in the kernel back in 1998,
> before any such a thing existed in the kernel, and made a little package of
> that. It supported a driver I was working on:
>
> http://www.kylheku.com/~kaz/lmc.html
>
> A few years ago, on another job, I also wrote a "super poll function".
> With this bugger, you could, simultaneously:
>
> - wait on a set of sockets (struct socket *)
> - wait on a set of files (struct file *)
> - wait on a condition variable
> - with a timeout

I just noticed that I had added that function to the above "LMC" project, haha.

--------------010208080807060702010400--

  1. 2015-05-02 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] Great Article on Software Concordance program writing
  2. 2015-05-02 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] Excellent article on Virtual Paging and OS memory
  3. 2015-05-02 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] Semephores and what the heck are those things?
  4. 2015-05-03 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] digital advert fraud
  5. 2015-05-03 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] Go Language tutorials
  6. 2015-05-03 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] Journal Club meeting
  7. 2015-05-03 Elfen Magix <elfen_magix-at-yahoo.com> Re: [NYLXS - HANGOUT] Journal Club meeting
  8. 2015-05-03 Ruben Safir <mrbrklyn-at-panix.com> Re: [NYLXS - HANGOUT] Journal Club meeting
  9. 2015-05-03 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] Re: Journal Article
  10. 2015-05-03 Rick Moen <rick-at-linuxmafia.com> Re: [NYLXS - HANGOUT] Journal Club meeting
  11. 2015-05-03 Ruben Safir <mrbrklyn-at-panix.com> Re: [NYLXS - HANGOUT] Journal Club meeting
  12. 2015-05-03 Rick Moen <rick-at-linuxmafia.com> Re: [NYLXS - HANGOUT] Journal Club meeting
  13. 2015-05-03 Rick Moen <rick-at-linuxmafia.com> Re: [NYLXS - HANGOUT] Journal Club meeting
  14. 2015-05-03 Ruben Safir <mrbrklyn-at-panix.com> Re: [NYLXS - HANGOUT] Journal Club meeting
  15. 2015-05-03 Rick Moen <rick-at-linuxmafia.com> Re: [NYLXS - HANGOUT] Journal Club meeting
  16. 2015-05-03 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] Movie of the week
  17. 2015-05-03 Ruben Safir <mrbrklyn-at-panix.com> Re: [NYLXS - HANGOUT] Journal Club meeting
  18. 2015-05-03 Rick Moen <rick-at-linuxmafia.com> Re: [NYLXS - HANGOUT] Journal Club meeting
  19. 2015-05-04 Rick Moen <rick-at-linuxmafia.com> Re: [NYLXS - HANGOUT] Journal Club meeting
  20. 2015-05-04 Ruben Safir <mrbrklyn-at-panix.com> Re: [NYLXS - HANGOUT] Journal Club meeting
  21. 2015-05-04 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] Fwd: a second look at storage and pointer fundamentals
  22. 2015-05-04 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] Fwd: Kernel Scheduling and wait queues
  23. 2015-05-04 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] Fwd: [Perlweekly] #197 - YAPC::EU Master classes - talks - hackathons
  24. 2015-05-04 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] Fwd: [ Khal Tiferes Yaakov ] Lag B'Omer in Passaic
  25. 2015-05-05 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] Nice possible project for NYLXS or others
  26. 2015-05-06 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] Fwd: Tomorrow: You're hosting "Journal Club Meetings"
  27. 2015-05-08 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] Things to study over the summer
  28. 2015-05-08 Ruben Safir <mrbrklyn-at-panix.com> Re: [NYLXS - HANGOUT] Things to study over the summer
  29. 2015-05-08 adrba-at-nyct.net Re: [NYLXS - HANGOUT] Things to study over the summer
  30. 2015-05-08 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] Fwd: Re: Kernel Scheduler and wiat queues
  31. 2015-05-09 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] Movies of the Week
  32. 2015-05-10 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] scheduler Slides
  33. 2015-05-10 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] Re: [LIU Comp Sci] scheduler Slides
  34. 2015-05-11 Ruben Safir <ruben.safir-at-my.liu.edu> Subject: [NYLXS - HANGOUT] Re: [LIU Comp Sci] scheduler Slides
  35. 2015-05-11 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] Re: [LIU Comp Sci] scheduler Slides
  36. 2015-05-12 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] jobs
  37. 2015-05-12 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] Job sound like this evenings lectures
  38. 2015-05-12 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] LAMP Jobs
  39. 2015-05-13 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] April Journal is Available
  40. 2015-05-13 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] Fwd: Tomorrow: You and 256 others are going to "Btrfs"
  41. 2015-05-13 mrbrklyn-at-panix.com Subject: [NYLXS - HANGOUT] [member-at-linkedin.com: RE: April Journal is Available]
  42. 2015-05-13 Ruben Safir <mrbrklyn-at-panix.com> Subject: [mrbrklyn-at-panix.com: Re: [NYLXS - HANGOUT] Things to study over the
  43. 2015-05-13 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] Malloc systemtap probes: an example
  44. 2015-05-13 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] Stackiq - Educational Program
  45. 2015-05-14 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] Weekly Education Meeting
  46. 2015-05-17 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] ssh hack
  47. 2015-05-18 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] Fwd: [manjaro-general] Manjaro 0.8.13-rc1 released
  48. 2015-05-18 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] Fwd: [Perlweekly] #199 - Rust 1.0 is out!
  49. 2015-05-18 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] Check This Out
  50. 2015-05-18 adrba-at-nyct.net Re: [NYLXS - HANGOUT] Check This Out
  51. 2015-05-18 Elfen Magix <elfen_magix-at-yahoo.com> Re: [NYLXS - HANGOUT] Check This Out
  52. 2015-05-18 mrbrklyn-at-panix.com Subject: [NYLXS - HANGOUT] [jkeen-at-verizon.net: ny.pm Technical Meeting Wed May 20 6:15 pm]
  53. 2015-05-19 Rick Moen <rick-at-linuxmafia.com> Re: [NYLXS - HANGOUT] Check This Out
  54. 2015-05-19 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] copyright vrs free speach on utube
  55. 2015-05-19 Ruben Safir <mrbrklyn-at-panix.com> Re: [NYLXS - HANGOUT] Check This Out
  56. 2015-05-19 Ruben Safir <mrbrklyn-at-panix.com> Re: [NYLXS - HANGOUT] Check This Out
  57. 2015-05-19 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] Weapons of Mass Destruction my ass
  58. 2015-05-19 Robert Menes <viewtiful.icchan-at-gmail.com> Re: [NYLXS - HANGOUT] Check This Out
  59. 2015-05-19 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] NYLXS
  60. 2015-05-19 Rick Moen <rick-at-linuxmafia.com> Re: [NYLXS - HANGOUT] Check This Out
  61. 2015-05-20 Ruben Safir <mrbrklyn-at-panix.com> Re: [NYLXS - HANGOUT] Check This Out
  62. 2015-05-21 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] Free Software Business
  63. 2015-05-25 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] Summer NYLXS Study Schedule
  64. 2015-05-26 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] C++ maheim
  65. 2015-05-26 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] Fwd: IEEE NY Meeting Announcement
  66. 2015-05-27 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] Plane Hacking
  67. 2015-05-27 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] Oracle attach on Android Copyright
  68. 2015-05-28 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] adblock is legal... who knew?
  69. 2015-05-28 mrbrklyn-at-panix.com Subject: [NYLXS - HANGOUT] Steeley Dan in NYC
  70. 2015-05-28 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] Fwd: privacy and data security
  71. 2015-05-28 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] Fwd: Please give to the Houston Relief Fund
  72. 2015-05-28 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] Fwd: Please give to the Houston Relief Fund
  73. 2015-05-28 mrbrklyn-at-panix.com Subject: [NYLXS - HANGOUT] [ruben-at-www.mrbrklyn.com: Linux 1 Book]
  74. 2015-05-29 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] Minting Money with Free software
  75. 2015-05-31 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] anyone familiar with STM?

NYLXS are Do'ers and the first step of Doing is Joining! Join NYLXS and make a difference in your community today!