FileSystem synchronous reads?

[Brad Rydzewski]

What is the best way to retrieve data from the HTML5 FileSystem
synchronously? As my native code is running, it attempts to open files
using fopen for processing ... i'm trying to replace this code with
extern methods that use FileSystem_Dev and the HTML5 Filesystem.
Just as a side note -- users will be creating and editing these files
in the browser, so I cannot pre-load them.

I am using Chrome 13 and have the appropriate flags enabled. Here is
some sample code for reference:

pp::FileSystem_Dev file_system_pers(instance,
PP_FILESYSTEMTYPE_LOCALPERSISTENT);
int32_t rv = file_system_pers.Open(1024*1024, callback);

I was trying to use callback with Block in the constructor for force
Synchronous behavior
pp::CompletionCallback callback =
pp::CompletionCallback(pp::CompletionCallback::Block());

If I use this callback, I get PP_ERROR_BADARGUMENT. I dug into the
header files and it seems like blocking a callback is only allowed
when executing inside a thread. So I also tried using callback.Run to
force synchronous execution, but it returns PP_OK_COMPLETIONPENDING.

I then tried using a while loop to block the current thread until the
callback method was invoked, however, it seems the callback is blocked
until the while loop is finished executing.

I was hoping that I could get some advice on how to get this working

[Brett Wilson]

Hi Brad,

Unfortunately, background thread stuff isn't implemented yet. I would
look for that late this year. This means there's no official way to
read files synchronously using the Pepper API.

NaCl may have a way to do this with C stdlib style calls, maybe
somebody who's more familiar with that can chime in.

If that doesn't work and you really need this to make your code work,
the way to do this is to write your own asynchronous code on the main
thread that makes the call synchronous on the background thread where
your code is running. Sorry this isn't easier yet.

Brett

[Victor Khimenko]

On Wed, Jul 13, 2011 at 7:39 PM, Brett Wilson <bre...@chromium.org> wrote:

Unfortunately, background thread stuff isn't implemented yet. I would

look for that late this year. This means there's no official way to
read files synchronously using the Pepper API.

NaCl may have a way to do this with C stdlib style calls, maybe
somebody who's more familiar with that can chime in.

Nope. stdlib C style calls are only usable in sel_ldr's debug mode. We have some hack which is used to test glibc in browser, but it uses some deprecated IMC magic and is one of the reasons we kept newlib in M14 SDK...

[Darin Fisher]

It was my understanding that we intend to support *most* synchronous calls to PPB_FileIO

from a NaCl module for M14.  I believe that Open will not be supported though.

(Also, please note that functions that synchronous calls to PPB_FileIO will only be supported

from a background thread.  They are not supported on the main thread.)

-Darin

[Victor Khimenko]

On Wed, Jul 13, 2011 at 8:38 PM, Darin Fisher <da...@chromium.org> wrote:

It was my understanding that we intend to support *most* synchronous calls to PPB_FileIO from a NaCl module for M14.  I believe that Open will not be supported though.

And this is exactly what the GLibC needs. Low-level and ubiquitous functions like printf or pthread_cancel need synchronous, thread-safe open syscall. Granted: it's only on slow pass when you call them the first time (or when something significant like "system locale" changes) so you can try to survive without synchronous open() call but this is so, sooo, fragile.

[Darin Fisher]

On Wed, Jul 13, 2011 at 11:39 PM, Victor Khimenko <kh...@google.com> wrote:

On Wed, Jul 13, 2011 at 8:38 PM, Darin Fisher <da...@chromium.org> wrote:

It was my understanding that we intend to support *most* synchronous calls to PPB_FileIO from a NaCl module for M14.  I believe that Open will not be supported though.

And this is exactly what the GLibC needs. Low-level and ubiquitous functions like printf or pthread_cancel need synchronous, thread-safe open syscall. Granted: it's only on slow pass when you call them the first time (or when something significant like "system locale" changes) so you can try to survive without synchronous open() call but this is so, sooo, fragile.

The plan is to eventually support the entire Pepper API on background threads.  The API was designed as such.  There will never be support for synchronous File IO on the main thread though.

-Darin

 

 

(Also, please note that functions that synchronous calls to PPB_FileIO will only be supported from a background thread.  They are not supported on the main thread.)

--
You received this message because you are subscribed to the Google Groups "Native-Client-Discuss" group.
To post to this group, send email to native-cli...@googlegroups.com.
To unsubscribe from this group, send email to native-client-di...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/native-client-discuss?hl=en.

[Victor Khimenko]

On Thu, Jul 14, 2011 at 8:31 PM, Darin Fisher <da...@chromium.org> wrote:

The plan is to eventually support the entire Pepper API on background threads.  The API was designed as such.  There will never be support for synchronous File IO on the main thread though.

This will mean most stdlib functions will be forbidden on main thread (including printf, etc). We'll see how it'll work when we'll reach this state.

[Darin Fisher]

Right.  Although, one could imagine exposing a PPB_Console interface that provides for things like stdout.  Imagine if printf were hooked up to the developer tools console!

-Darin

[Darin Fisher]

On Thu, Jul 14, 2011 at 10:17 AM, Darin Fisher <da...@chromium.org> wrote:

On Thu, Jul 14, 2011 at 10:02 AM, Victor Khimenko <kh...@google.com> wrote:

On Thu, Jul 14, 2011 at 8:31 PM, Darin Fisher <da...@chromium.org> wrote:

The plan is to eventually support the entire Pepper API on background threads.  The API was designed as such.  There will never be support for synchronous File IO on the main thread though.

This will mean most stdlib functions will be forbidden on main thread (including printf, etc). We'll see how it'll work when we'll reach this state.

Right.  Although, one could imagine exposing a PPB_Console interface that provides for things like stdout.  Imagine if printf were hooked up to the developer tools console!

-Darin

Actually, you don't need to imagine it.  We already have PPB_Console_Dev::Log :-)

[Jeff Ward]

Actually, you don't need to imagine it.  We already have PPB_Console_Dev::Log :-)

Does PPB_Console_Dev work in Nacl 0.4 / Chrome 13?  Calling out to Module::GetBrowserInterface(PPB_CONSOLE_DEV_INTERFACE) is returning NULL for me.

--

Jeff

[Darin Fisher]

Sorry, looks like it is not proxied yet.  For now, you would need to use PostMessage, and then call console.log from JS :-(