[prev in list] [next in list] [prev in thread] [next in thread]
List: haskell-cafe
Subject: Re: [Haskell-cafe] Locking of threads in one OS thread
From: Sylvain Henry <hsyl20 () gmail ! com>
Date: 2014-08-26 14:59:42
Message-ID: CAPmptcUnxdLJmxGOHv7yGZUbSpWVOGAJBWj1bJkotZJTNQ=z1A () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
AFAIK "errno" is handled explicitly in the RTS:
https://ghc.haskell.org/trac/ghc/browser/ghc/rts/Schedule.c#L484
-Sylvain
2014-08-26 16:22 GMT+02:00 Nikolay Amiantov <nikoamia@gmail.com>:
>
> On Wed, Aug 20, 2014 at 4:36 PM, Alexander Kjeldaas <
> alexander.kjeldaas@gmail.com> wrote:
>
>> Reading errno directly after the FFI call can eliminate heap overflows,
>> but the async exception and timer issues still seem possible.
>>
>
> I have played around a bit and I can't understand what's going on with
> this anymore. Check out this example:
> https://gist.github.com/abbradar/76dafcee1807c9c5ac4d. Compile it with
> "ghc test_c.c test.hs". I used "mask_" here to check if it can fix the
> problem.
>
> There will be multiple discrepancies seen between written and read values
> because of threads preemption if my_errno is used. However, if you use
> "errno" (change #define for that) instead, everything seems good.
>
> Anyway, it looks like getErrno and friends rely on this magical behaviour
> of errno -- if some other library which uses global error state like
> "my_errno" in example is used (I remember SDL doing that, and I have also
> done it myself), there should be problems without some way to temporary
> disable threads preemption, which I haven't found. Hence -- should I maybe
> post a bug report about this?
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
>
[Attachment #5 (text/html)]
<div dir="ltr">AFAIK "errno" is handled explicitly in the RTS: <a \
href="https://ghc.haskell.org/trac/ghc/browser/ghc/rts/Schedule.c#L484">https://ghc.haskell.org/trac/ghc/browser/ghc/rts/Schedule.c#L484</a><br><br>
-Sylvain<br></div><div class="gmail_extra"><br><br><div \
class="gmail_quote">2014-08-26 16:22 GMT+02:00 Nikolay Amiantov <span \
dir="ltr"><<a href="mailto:nikoamia@gmail.com" \
target="_blank">nikoamia@gmail.com</a>></span>:<br> <blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"><div dir="ltr"><div class=""><br><div \
class="gmail_extra"><div class="gmail_quote">On Wed, Aug 20, 2014 at 4:36 PM, \
Alexander Kjeldaas <span dir="ltr"><<a href="mailto:alexander.kjeldaas@gmail.com" \
target="_blank">alexander.kjeldaas@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid \
rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div \
class="gmail_quote"><div>Reading errno directly after the FFI call can eliminate heap \
overflows, but the async exception and timer issues still seem possible.<br>
<span></span><span></span></div></div></div></div>
</blockquote></div><br></div></div><div class="gmail_extra">I have played around a \
bit and I can't understand what's going on with this anymore. Check out this \
example: <a href="https://gist.github.com/abbradar/76dafcee1807c9c5ac4d" \
target="_blank">https://gist.github.com/abbradar/76dafcee1807c9c5ac4d</a>. Compile it \
with "ghc test_c.c test.hs". I used "mask_" here to check if it \
can fix the problem.<br>
<br></div><div class="gmail_extra">There will be multiple <span \
lang="en"><span>discrepancies seen between written and read values because of threads \
preemption if my_errno is used. However, if you use "errno" (change #define \
for that) instead, everything seems good.<br>
<br></span></span></div><div class="gmail_extra"><span lang="en"><span>Anyway, it \
looks like getErrno and friends rely on this magical behaviour of errno -- if some \
other library which uses global error state like "my_errno" in example is \
used (I remember SDL doing that, and I have also done it myself), there should be \
problems without some way to temporary disable threads preemption, which I \
haven't found. Hence -- should I maybe post a bug report about this?<br>
</span></span></div></div>
<br>_______________________________________________<br>
Haskell-Cafe mailing list<br>
<a href="mailto:Haskell-Cafe@haskell.org">Haskell-Cafe@haskell.org</a><br>
<a href="http://www.haskell.org/mailman/listinfo/haskell-cafe" \
target="_blank">http://www.haskell.org/mailman/listinfo/haskell-cafe</a><br> \
<br></blockquote></div><br></div>
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic