OSDev.org

The Place to Start for Operating System Developers
It is currently Fri Mar 29, 2024 7:44 am

All times are UTC - 6 hours




Post new topic Reply to topic  [ 2 posts ] 
Author Message
 Post subject: RFC: implementing 'poll'.
PostPosted: Tue May 24, 2016 2:14 pm 
Offline
Member
Member

Joined: Fri May 01, 2015 2:23 am
Posts: 63
Hi.

Still working on my VFS design. I try to come up with a fast yet still somewhat simple (from device point of view) way of implementing poll (i.e. waiting until one or more open files can be read/written).

I know how Linux implements it, so that is one option (i.e. devices add thread wait queues to a list maintained by kernel, device wait queue wakes the thread up once data can be transmitted, and kernel tears the list down). I don't like the overhead of building the list of wait queues, and tearing them down after every poll.

My latest iteration is based on an idea that a thread can execute only a single poll at a time, and that a thread typically keeps polling the same file handles over and over again. My device drivers are implemented as (possibly separate) service process(es), and the poll mechanism would be part of the VFS service. This is how it's supposed to work:

Each thread that does a poll has a 'poll request structure' (PRS) in the VFS service. It contains a 'poll request sequence counter' (PRSC) and the thread id.
When a thread does a poll, the PRSC value is incremented. All device drivers involved in the poll store the PRS handle (in practice VFS service pointer to the structure) and the current PRSC value to each file that is part of the poll. The thread would then sleep until it receives a signal. Once a polled file can be read/written, the driver would iterate all PRSs in the file and ask the VFS to wake up the thread. If the current PRSC value matches the PRSC value stored by the device, VFS increments the PRSC value and sends a 'SIGPOLL' signal to the thread. This would be implemented in such a way that only one file will trigger the signal. There would not be any poll structure tear-down until the file is closed, but PRSC value comparison would prevent sending excess signals if other files become readable/writable after the thread has been woken up. Later, when the thread does a new poll, device drivers would just update the PRSC values stored in the polled files, so that new data would trigger a new signal to wake up the thread.

Please comment if you find problems or flaws in my logic, and tell how you implement 'poll' in your OS.

_________________
Hellbender OS at github.


Top
 Profile  
 
 Post subject: Re: RFC: implementing 'poll'.
PostPosted: Fri May 27, 2016 4:37 am 
Offline
Member
Member
User avatar

Joined: Wed Oct 18, 2006 3:45 am
Posts: 9301
Location: On the balcony, where I can actually keep 1½m distance
Quote:
and tell how you implement 'poll' in your OS.
By refusing to have blocking calls and instead have devices send messages straight to the process when a resource becomes available. :wink:

For a more traditional synchronous poll, you could have polling objects maintained in the kernel, which is for most part about moving overhead around, possibly hiding it in another thread to make the calling thread look faster. I'd probably have an interface as follows
- CreatePollGroup
- DeletePollGroup
- AddObjectToPollGroup
- RemoveObjectFromPollGroup
- Poll
- PollWithTimeout

On average this causes more overhead in raw system call code instead of having a Poll(object, object, ...) function as you might need to update the stateful polling objects in between.

_________________
"Certainly avoid yourself. He is a newbie and might not realize it. You'll hate his code deeply a few years down the road." - Sortie
[ My OS ] [ VDisk/SFS ]


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 2 posts ] 

All times are UTC - 6 hours


Who is online

Users browsing this forum: No registered users and 35 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group