Marcin 'Qrczak' Kowalczyk wrote:
>Ben Rudiak-Gould <[EMAIL PROTECTED]> writes:
>>fileRead can be implemented in terms of OS primitives,
>
>Only if they already support reading from a fixed offset (like pread).
>I'm not sure if we can rely on something like this being always
>available, or whether i
Ben Rudiak-Gould <[EMAIL PROTECTED]> writes:
> First of all, I don't think any OS shares file pointers between
> processes.
Unix does.
It's because shared files are usually stdin/stdout/stderr (I mean
that they are visible as stdin/stdout/stderr, rather than about their
nature as terminals - the
Ben Rudiak-Gould <[EMAIL PROTECTED]> writes:
> Marcin 'Qrczak' Kowalczyk wrote:
>> Ben Rudiak-Gould <[EMAIL PROTECTED]> writes:
>>
>>> fileRead can be implemented in terms of OS primitives,
>>
>> Only if they already support reading from a fixed offset (like pread).
>> I'm not sure if we can rely
On 20/01/2005, at 3:42 AM, Keean Schupke wrote:
Have you read the OOHaskell paper?
http://homepages.cwi.nl/~ralf/OOHaskell/
This shows how to encode many OO idioms in Haskell, without any
extensions
(beyond those that GHC already supports)... Here's some sample code
(from the Shapes.hs example)
Andre Pang wrote:
Just because you can encode the OO idioms in Haskell doesn't mean it's
particularly straightforward to use them. As your example shows,
getting the syntax right for these OOish constructs isn't easy (not to
mention verbose), and even so, the type errors you face when you get
On 20/01/2005, at 11:06 PM, Keean Schupke wrote:
I find it no harder than writing with monads for example... certainly
there are some
tricky things going on in both... but that doesn't stop people using
monads for IO,
state etc.
Syntactic sugar over the top for instance and implementation
defin
Andre Pang wrote:
The syntactic sugar is the killer. (Using monads is really no fun if
you don't have do notation, for example. Doable: yes. Pretty:
definitely not!) Even if you use Template Haskell to try to implement
the syntactic sugar, you're very limited by the splice $(...) notation
a
On 12 January 2005 01:27, Ben Rudiak-Gould wrote:
> First of all, I don't think any OS shares file pointers between
> processes. Otherwise it would be practically impossible to safely use
> an inherited filehandle via any API. Different threads using the same
> filehandle do share a file pointer (
Ferenc Wagner wrote:
> dup()-ed filehandles share a common file position.
They also share the file status flags (O_NONBLOCK, O_APPEND etc). So,
enabling or disabling non-blocking I/O will affect all descriptors
obtained by duplication (either by dup/dup2 or by fork).
OTOH, each descriptor has i
Marcin 'Qrczak' Kowalczyk wrote:
>Ben Rudiak-Gould <[EMAIL PROTECTED]> writes:
>>The file interface in this library is only used for files, which are
>>always seekable (by definition).
>
>What do you mean by files? What you get from open() is not always
>seekable [...]
This was all discussed a year
Simon Marlow wrote:
>I assumed that dup()'ing file descriptors would be enough to produce
>separate file pointers, but no.
Question (for qrczak or the group at large): is there *any* way to get,
without an exploitable race condition, two filehandles to the same file
which don't share a file point
Ben Rudiak-Gould <[EMAIL PROTECTED]> writes:
> is there *any* way to get, without an exploitable race condition,
> two filehandles to the same file which don't share a file pointer?
AFAIK it's not possible if the only thing you know is one of the
descriptors. Of course independent open() calls wh
Marcin 'Qrczak' Kowalczyk wrote:
Ben Rudiak-Gould <[EMAIL PROTECTED]> writes:
is there *any* way to get, without an exploitable race condition,
two filehandles to the same file which don't share a file pointer?
In unix the traditional way to do this is to use a directory. Each
process/thre
Keean Schupke <[EMAIL PROTECTED]> writes:
> At the end of the day IO is serial by nature (to one device anyway),
> so the way to do this into one file is to have one thread that reads
> and writes, and to 'send' read and write requests over channels from
> the threads that need the work done
Woul
No I meant Channels (from Data.Concurrent)... you can use a structure like:
data Command = Read FileAddr (MVar MyData) | Write FileAddr MyData
So to write you just do:
writeChan iochan (Write address data) -- returns immediately
-- write happens asynchronously later
and to read:
data <-
Keean Schupke <[EMAIL PROTECTED]> writes:
> No I meant Channels (from Data.Concurrent)... you can use a structure like:
Yes, I realize that (although I haven't yet used Data.Concurrent). It
seemed to me, though, that streams are related to channels, and that
it may be possible to use the same (o
Ketil Malde wrote:
Keean Schupke <[EMAIL PROTECTED]> writes:
No I meant Channels (from Data.Concurrent)... you can use a structure like:
Yes, I realize that (although I haven't yet used Data.Concurrent). It
seemed to me, though, that streams are related to channels, and that
it may be poss
Ketil Malde <[EMAIL PROTECTED]> writes:
> It seemed to me, though, that streams are related to channels,
I'm not sure what exactly do you mean by streams (because they are
only being designed), but differences are:
- A stream is either an input stream or an output stream, while a
single channe
Marcin 'Qrczak' Kowalczyk <[EMAIL PROTECTED]> writes:
> Ketil Malde <[EMAIL PROTECTED]> writes:
>> It seemed to me, though, that streams are related to channels,
> I'm not sure what exactly do you mean by streams (because they are
> only being designed), but differences are:
Sorry for being unc
> First of all, I don't think any OS shares file pointers between
> processes. Otherwise it would be practically impossible to safely use an
> inherited filehandle via any API. Different threads using the same
> filehandle do share a file pointer (which is a major nuisance in my
> experience, b
20 matches
Mail list logo
