Opening "Special" Files

[Jayson Vantuyl-2]

Dear Erlang Questions,

I really need to open a block device.  I'll treat it just like a file,  
I swear.  I'll open it.  I'll read from it.  I'll write to it.  I'll  
close it when I'm done.  I'll even cuddle if it wants to.  Where's the  
harm in that?

Unfortunately, there's a rather bureaucratic function called  
efile_may_openfile in erts/emulator/drivers/unix/unix_efile.c.  It's  
on line 800.  It insists that anything but a purely vanilla file just  
won't do.

As in:

>     808     if (!ISREG(statbuf)) {
>     809         errno = EISDIR;
>     810         return check_error(-1, errInfo);
>     811     }

Ignoring for the moment that synthesizing a system-level error that  
isn't really there is probably bad form, I would greatly enjoy a way  
to override this.  I should really not have to write my own port  
driver just to do this.  I don't want to have to figure out how to  
deal with the async IO pool in C.

Is this on the roadmap?  Can it be on the roadmap?  Is there a good  
workaround?

Also, can anyone even tell me why this is there?  Is there some odd  
behavior on an embedded system?  Is it a primitive attempt at a  
security feature?  Are we really afraid of getting SIGPIPE?

Thanks,

--
Jayson Vantuyl
[hidden email]




________________________________________________________________
erlang-questions mailing list. See http://www.erlang.org/faq.html
erlang-questions (at) erlang.org

[Mark Wagner]

On Mon, Aug 24, 2009 at 01:03, Jayson Vantuyl<[hidden email]> wrote:
> Dear Erlang Questions,
>
> I really need to open a block device.  I'll treat it just like a file, I
> swear.  I'll open it.  I'll read from it.  I'll write to it.  I'll close it
> when I'm done.  I'll even cuddle if it wants to.  Where's the harm in that?
>
> Unfortunately, there's a rather bureaucratic function called
> efile_may_openfile in erts/emulator/drivers/unix/unix_efile.c.  It's on line
> 800.  It insists that anything but a purely vanilla file just won't do.

> ...

> Also, can anyone even tell me why this is there?  Is there some odd behavior
> on an embedded system?  Is it a primitive attempt at a security feature?
>  Are we really afraid of getting SIGPIPE?

My understanding based on discussions on the mailing list is that this
is an effort to avoid blocking I/O: a OS-level block on read or write
would result in all Erlang-level threads managed by the current
process being suspended until the I/O completes or times out.

--
Mark Wagner

________________________________________________________________
erlang-questions mailing list. See http://www.erlang.org/faq.html
erlang-questions (at) erlang.org

[Jayson Vantuyl-2]

Isn't this prevented by the asynchronous I/O threading stuff (erl +A  
NNN)?  I'm unsure why a block device would be that different than a  
file in that case.  Both create a potentially random seek and both  
mitigate this with cache.

On Aug 25, 2009, at 6:22 PM, Mark Wagner wrote:
> My understanding based on discussions on the mailing list is that this
> is an effort to avoid blocking I/O: a OS-level block on read or write
> would result in all Erlang-level threads managed by the current
> process being suspended until the I/O completes or times out.

--
Jayson Vantuyl
[hidden email]




________________________________________________________________
erlang-questions mailing list. See http://www.erlang.org/faq.html
erlang-questions (at) erlang.org

[Ciprian Dorin Craciun]

On Wed, Aug 26, 2009 at 4:30 AM, Jayson Vantuyl<[hidden email]> wrote:

> Isn't this prevented by the asynchronous I/O threading stuff (erl +A NNN)?
>  I'm unsure why a block device would be that different than a file in that
> case.  Both create a potentially random seek and both mitigate this with
> cache.
>
> On Aug 25, 2009, at 6:22 PM, Mark Wagner wrote:
>>
>> My understanding based on discussions on the mailing list is that this
>> is an effort to avoid blocking I/O: a OS-level block on read or write
>> would result in all Erlang-level threads managed by the current
>> process being suspended until the I/O completes or times out.
>
> --
> Jayson Vantuyl
> [hidden email]

    Indeed earlier (this year or last one) there was a similar
discussion on the mailing list... And the result was as Mark pointed,
that for a regular file there is no risk of having the read or write
operation stall...

    Unfortunately I must say that this protection is not
bullet-proof... For example I've played a lot with FUSE (File System
in User Space), and it is very easy to create virtual regular files,
for which read or write could stall...

    As a conclusion, I would propose to allow the user to specify a
flag that would force OTP (at the risk of the user) to open any file.
(Of course I don't think such a thing would be implemented...)

    So if you really want to be able to open any kind of file from
Erlang (I mean here block devices, character devices, fifo's, unix
domain sockets, etc.) You could just implement a simple FUSE
application in C to wrap the file system (this would be reusable for
other projects with similar problems)... (Or as you've said write a
port-like process or driver...)

    Ciprian Craciun.

________________________________________________________________
erlang-questions mailing list. See http://www.erlang.org/faq.html
erlang-questions (at) erlang.org