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

Submitter:  Sandro Santilli <strk>
Submitted:  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
Assigned to:  strk Percent Complete:  100%
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>
Group Member
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>
Group Member
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>
Group Member
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>
Group Member

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

No files currently attached

 

Depends on the following items: None found

Digest:
   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)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

     

    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 -email is unavailable-
    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.13-758e.
    Corresponding source code