Hi Michael,
Are you already using usb-1.3.0.0? If not, could you upgrade and test
again? That release fixed the deadlock that Ben and Carter where
talking about.
Good luck,
Bas
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
Bas,
I have not upgraded, mainly because my problems manifest without enabling USB.
However, I think I can upgrade in a few days and move forward.
Are you using ghc 7.8.10 these days or something older?
Mike
On Jan 21, 2015, at 12:52 PM, Bas van Dijk v.dijk@gmail.com wrote:
Hi Michael,
Bas,
I checked my cabal file and I was already using 1.3.0.0.
Mike
On Jan 21, 2015, at 12:52 PM, Bas van Dijk v.dijk@gmail.com wrote:
Hi Michael,
Are you already using usb-1.3.0.0? If not, could you upgrade and test
again? That release fixed the deadlock that Ben and Carter where
On 21/01/2015 03:43, Michael Jones wrote:
Simon,
The code below hangs on the frameEx function.
But, if I change it to:
f - frameCreate objectNull idAny linti-scope PMBus Scope Tool
rectZero (frameDefaultStyle .|. wxMAXIMIZE)
it will progress, but no frame pops up, except once in
woops, forgot to attach the relevant links, (i shouldn't email late at
night :) )
https://github.com/basvandijk/usb/issues/7 is the lib usb matter
https://phabricator.haskell.org/D347
point being: on ghc 7.8, certain hanging behavior from libusb (at least as
of a few months ago) was due to one
Simon,
I went back and retested my non-GUI version and it seems to work fine. But here
is what is strange, the non-GUI version is really just a client server version
of what I have problems with. I have a non-GUI app running the USB and
streaming data to a server. The client app (the one that
Simon,
This was fixed some time back. I combed the code base looking for other busy
loops and there are no more. I commented out the code that runs the I2C +
Machines + IO stuff, and only left the GUI code. It appears that just the
wxhaskell part of the program fails to start. This matches a
My guess would be that either
- a thread is in a non-allocating loop
- a long-running foreign call is marked unsafe
Either of these would block the other threads. ThreadScope together
with some traceEventIO calls might help you identify the culprit.
Cheers,
Simon
On 20/01/2015 15:49,
Simon,
The code below hangs on the frameEx function.
But, if I change it to:
f - frameCreate objectNull idAny linti-scope PMBus Scope Tool
rectZero (frameDefaultStyle .|. wxMAXIMIZE)
it will progress, but no frame pops up, except once in many tries. Still hangs,
but progresses
i think ben gamari hit similar/related issues with the lib usb bindings in
7.8, and i believe some / all of them are fixed in 7.10
(i could be mixing things up though)
On Tue, Jan 20, 2015 at 10:43 PM, Michael Jones m...@proclivis.com wrote:
Simon,
The code below hangs on the frameEx
Hi Michael,
Previously in this thread it was pointed out that your code was doing
busy waiting, and so the problem can be fixed by modifying your code to
not do busy waiting. Did you do this? The -C flag is just a workaround
which will make the RTS reschedule more often, it won't fix the
Donn,
True, but in that case I was using a driver for the Aardvark, and my current
two test cases use:
A) DC1613A from LTC
B) /dev/i2c driver with FFI wrapper I wrote
Case A uses the haskell usb package and libusb. I suppose SIGVALRM could be in
used in the libusb driver. I know for sure it
I have narrowed down the problem a bit. It turns out that many times if I run
the program and wait long enough, it will start. Given an event log, it may
take from 1000-1 entries sometimes.
When I look at a good start vs. slow start, I see that in both cases things
startup and there is
Quoth Michael Jones m...@proclivis.com,
...
5) What does -V0 do that makes a problem program run?
Well, there's that SIGVTALRM barrage, you may remember we went
over that mid-August. I expect there are other effects.
Donn
___
Michael Jones m...@proclivis.com writes:
Sorry I am reviving an old problem, but it has resurfaced, such that
one system behaves different than another.
[snip]
1) Does ghc 7.8.4 have any improvements that might pertain to these kinds of
scheduling/thread problems?
2) Is there anything
Ben,
Interesting.
In this case, I can duplicate the problem when not using USB (USB to i2c
dongle) by using /dev/i2c_n, and when I do use USB, in some cases the USB is
working (can see i2c on scope), but the GUI is hung. So I believe this is not
causing the problem.
Thanks,
Mike
On Jan 13,
Sorry I am reviving an old problem, but it has resurfaced, such that one system
behaves different than another.
Using -C0.001 solved problems on a Mac + VM + Ubuntu 14. It worked on a single
core 32 bit Atom NUC. But on a dual core Atom MinnowBoardMax, something bad is
going on. In summary,
...@haskell.org] On Behalf Of Edward Z. Yang
| Sent: 30 October 2014 00:41
| To: John Lato
| Cc: GHC Users List
| Subject: Re: Thread behavior in 7.8.3
|
| Yes, that's right.
|
| I brought it up because you mentioned that there might still be
| occasional delays, and those might be caused
My hope is that if my threads are doing IO, the scheduler acts when there is an
IO action with delay, or when STM blocks, etc.
So at the end of my pipe out, I have:
sendTransactions :: MonadIO m = SMBusDevice DeviceDC590 - TVar Bool -
ProcessT m (Spec, String) ()
sendTransactions dev dts =
Hmm, I think maybe part of the problem is in your STM blocks.
On Thu, Oct 30, 2014 at 8:50 AM, Michael Jones m...@proclivis.com wrote:
My hope is that if my threads are doing IO, the scheduler acts when there
is an IO action with delay, or when STM blocks, etc.
So at the end of my pipe out,
Michael Jones m...@proclivis.com writes:
I have a general question about thread behavior in 7.8.3 vs 7.6.X
I moved from 7.6 to 7.8 and my application behaves very differently. I
have three threads, an application thread that plots data with
wxhaskell or sends it over a network (depends on
Ben,
I am using Bas van Dijk’s usb, and I am past the -threading issue by using the
latest commit.
I don’t have any easy way of making comparisons between 7.6 and 7.8
productivity, but from oscilloscope activity, I can’t see any difference. The
only difference I see is the thread scheduling
Michael Jones m...@proclivis.com writes:
Ben,
I am using Bas van Dijk’s usb, and I am past the -threading issue by
using the latest commit.
Excellent; I hadn't noticed the proclivis in your email address
I don’t have any easy way of making comparisons between 7.6 and 7.8
productivity, but
By any chance do the delays get shorter if you run your program with `+RTS
-C0.005` ? If so, I suspect you're having a problem very similar to one
that we had with ghc-7.8 (7.6 too, but it's worse on ghc-7.8 for some
reason), involving possible misbehavior of the thread scheduler.
On Wed, Oct
John,
Adding -C0.005 makes it much better. Using -C0.001 makes it behave more like
-N4.
Thanks. This saves my project, as I need to deploy on a single core Atom and
was stuck.
Mike
On Oct 29, 2014, at 5:12 PM, John Lato jwl...@gmail.com wrote:
By any chance do the delays get shorter if you
I guess I should explain what that flag does...
The GHC RTS maintains capabilities, the number of capabilities is specified
by the `+RTS -N` option. Each capability is a virtual machine that
executes Haskell code, and maintains its own runqueue of threads to process.
A capability will perform a
I don't think this is directly related to the problem, but if you have a
thread that isn't yielding, you can force it to yield by using
-fno-omit-yields on your code. It won't help if the non-yielding code
is in a library, and it won't help if the problem was that you just
weren't setting
Yes, that's right.
I brought it up because you mentioned that there might still be
occasional delays, and those might be caused by a thread not being
preemptible for a while.
Edward
Excerpts from John Lato's message of 2014-10-29 17:31:45 -0700:
My understanding is that -fno-omit-yields is
28 matches
Mail list logo
