taskGnash - The GNU Flash player - Tasks: task #6962, Add non-blocking IO interfaces to...


You are not allowed to post comments on this tracker with your current authentication level.

task #6962: Add non-blocking IO interfaces to IOChannel

Submitted by:  Sandro Santilli <strk>
Submitted on:  Thu 31 May 2007 02:03:45 PM UTC  
Should Start On:  Wed 30 May 2007 10:00:00 PM UTC Should be Finished on:  Wed 30 May 2007 10:00:00 PM UTC
Category:  None Priority:  7 - High
Status:  Done Privacy:  Public
Percent Complete:  100% Assigned to:  Sandro Santilli <strk>
Open/Closed:  Closed Effort:  0.00

Sun 08 Nov 2009 12:03:51 AM UTC, comment #3: 

Well, this is in common use by now, so it's considered closed.
When improvements are needed it'd be best to open new tasks.

Sandro Santilli <strk>
Project MemberIn charge of this item.
Sat 12 Jul 2008 12:34:13 AM UTC, comment #2: 

Well, finally started this, not as planned, but started.
There's now an IOChannel::readNonBlocking() interface,
always returning the actual amount of bytes read, and reading
as much as possible from the cache.

Sandro Santilli <strk>
Project MemberIn charge of this item.
Fri 06 Jun 2008 09:22:19 PM UTC, comment #1: 

Alright, here's the idea (more clear after one year:)

- will need to expose getBytesLoaded() interface
- will need to expose canRead(x) interface
- will need to expose canSeekTo(x) interface

With the three above (which are basically 2, as canRead
could be implemented in terms of canSeekTo), we'll have non-blocking reads available.

Now, the first advantage is that we don't need to change
users of it. Users that just ::read() will block, while
users we'll update will be smarter.

In the current situation, the smarter users use a LoadThread,
which embeds a tu_file and provides those interfaces. This is
a waste for filesystem files, which wouldn't be needed if tu_file
supported that natively: filesystem-based tu_file would implement those calls w/out needing a thread.
Also, if tu_file supports that natively, the curl_adapter might
use a single thread to load data from any instances, using a single select-based loop and sleepign most of the time.

Marking this as the first 20% progress.

Note that the current NetSTreamFfmpeg is not using a loader thread yet because doing so would take changing a lot of code
from tu_file to LoadThread, and that isn't as easy as expanding
the tu_file interface directly...

Sandro Santilli <strk>
Project MemberIn charge of this item.
Thu 31 May 2007 02:03:45 PM UTC, original submission:  

This would be needed to remove the need of separate thread just for simulating async reads...

Acutually, as usual, we might drop tu_file as a whole, but I think it's not that bad to keep it and add the non-blocking reads instead, less work and as much effective, since we have lots of adaptors to it anyway..

Sandro Santilli <strk>
Project MemberIn charge of this item.


No files currently attached


Depends on the following items: None found

   task dependencies.


Carbon-Copy List
  • -email is unavailable- added by jasonwoof (I'm working on NetConnection.call())
  • -email is unavailable- added by strk (Submitted the item)

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.




    Follow 10 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2009-11-08 strk StatusNone => Done
        Percent Complete30% => 100%
        Assigned toNone => strk
        Open/ClosedOpen => Closed
    2008-07-12 jasonwoof Carbon-Copy- => Added jason260@herkamire.com
    2008-07-12 strk Percent Complete20% => 30%
    2008-06-10 strk SummaryAdd non-blocking IO interfaces to tu_file => Add non-blocking IO interfaces to IOChannel
    2008-06-06 strk Priority1 - Later => 7 - High
        Percent Complete0% => 20%
    2007-05-31 strk Dependencies- => task #6960 is dependent

    Back to the top

    Powered by Savane 3.5