Re: foreignObjToAddr

2000-02-17 Thread Manuel M. T. Chakravarty
[EMAIL PROTECTED] (Marcin 'Qrczak' Kowalczyk) wrote, > I use C2HS libraries now (but the c2hs program needs so *MUCH* > memory and time to parse Perl headers that I can't use it here; > fortunately there is no need to marsh C structures). The last version of C->HS on the Web page has a *big* sp

RE: foreignObjToAddr

2000-02-17 Thread Sigbjorn Finne
Manuel M. T. Chakravarty <[EMAIL PROTECTED]> writes: > > > > > Passing foreign objects directly via the FFI does not have this > > problem, because there is a special lifetime guarantee for this > > kind of values. :-P > > Actually, doesn't that prove the point that I tried to make > whe

Re: foreignObjToAddr

2000-02-17 Thread Manuel M. T. Chakravarty
Sven Panne <[EMAIL PROTECTED]> wrote, > Marcin 'Qrczak' Kowalczyk wrote: > > The function is described as unsafe because the result loses the > > finalizer, right? [...] > > Not exactly. The real problem (pointed out to me by Manuel Chakravarty > some time ago) is exemplified by the following co

Re: Trivial Haskell Concurrency problem

2000-02-17 Thread Tom Pledger
George Russell writes: > Tom Pledger wrote: > > For two threads to have access to the same MVar, they must have a > > common ancestor, right? Could a common ancestor spawn a transaction > > broker thread? That would be similar to what database management > > systems do. It'd still be centr

Re: foreignObjToAddr

2000-02-17 Thread Marcin 'Qrczak' Kowalczyk
Thu, 17 Feb 2000 12:04:52 +0100, Sven Panne <[EMAIL PROTECTED]> pisze: > Not exactly. The real problem (pointed out to me by Manuel Chakravarty > some time ago) is exemplified by the following code snippet: [...] I had exactly that thing in mind. Thu, 17 Feb 2000 14:21:12 +0100, Sven Panne <[E

Re: Trivial Haskell Concurrency problem

2000-02-17 Thread George Russell
George Russell wrote: > with comparison done in (at most) a logarithmic > number of steps. Damn. I really should have thought this through before making such an assertion. You can contrive a sequence of calls that will force comparison to take a linear number of steps. And I don't know how you

Re: foreignObjToAddr

2000-02-17 Thread Sven Panne
Marcin 'Qrczak' Kowalczyk wrote: > The function is described as unsafe because the result loses the > finalizer, right? [...] Not exactly. The real problem (pointed out to me by Manuel Chakravarty some time ago) is exemplified by the following code snippet: addr <- foreignObjToAddr fo -- las

Re: Trivial Haskell Concurrency problem

2000-02-17 Thread George Russell
George Russell wrote: > > George Russell wrote: > > Exactly the same happens at the same time to Processor 2. > > Now somehow you have to distinguish between Processor 1 and Processor 2, > > because only one is going to get to lower the flags. But I don't think > > with the existing Concurrency

RE: Wanted: mmap or other fast IO

2000-02-17 Thread Simon Marlow
> On 16-Feb-2000, Simon Marlow <[EMAIL PROTECTED]> wrote: > > > > The easiest way is to declare mmap as a foreign function > using foreign > > import, then build a little wrapper around it. > Unfortunately you won't be > > able to turn the resulting memory into an array (even a > ByteArray),

RE: foreignObjToAddr

2000-02-17 Thread Simon Marlow
> The function is described as unsafe because the result loses the > finalizer, right? > > So it is in fact unsafe to store a list of such Addrs in malloced > memory, passing the pointer to the array to a C function, because > they can be garbage collected and finalized during storing them, > bef

foreignObjToAddr

2000-02-17 Thread Marcin 'Qrczak' Kowalczyk
The function is described as unsafe because the result loses the finalizer, right? So it is in fact unsafe to store a list of such Addrs in malloced memory, passing the pointer to the array to a C function, because they can be garbage collected and finalized during storing them, before the C func