**@wiffel, @Araq:**
Thanks a lot! I really missed that it's impossible to use spawn with closures.
:(
So the sample should look like below one. It's much more verbose, but it works
properly.
import unicode, locks, os
proc lenU*(s: string): int =
result = s.runeLen
**@euant:**
> I believe the below code does the same thing as you're trying to achieve,
> though I think I might be misunderstanding your aim - as it stands, there
> seems to be no reason to use threads whatsoever?
The idea was: check how easiy (or hard) is to write in nim the app calling
pred
wiffel ist completely correct, and the compiler NEEDs to refuse this program.
You cannot pass a .closure proc to spawn.
In the original code, the **worker** proc is a _closure_. And **worker** does
indeed access some of the variables in the surrounding context.
I think that passing a _closure_ to **spawn** is not allowed. Since all threads
are potentially running within a separate memoryspace, I'm not even sure h
Hi,
I believe the below code does the same thing as you're trying to achieve,
though I think I might be misunderstanding your aim - as it stands, there seems
to be no reason to use threads whatsoever?
import unicode, threadpool, locks, os
proc lenU*(s: string): int =
> Well, I'm done with ideas. If you want to investigate further, I guess gdb or
> lldb would be able to help you see what's happening.
Anyway thank you for this discussion!
Yes I also have no ideas. The C code produced is quite big: 23982 lines
compiled, hmm... And I'm unfamiliar with internals
Well, I'm done with ideas. If you want to investigate further, I guess gdb or
lldb would be able to help you see what's happening.
Hi flux!
Thank you for your interest to this problem.
Well...
All you write is almost perfect, but in practice if we execute 10-20 threads
then scheduler wakes up these T1, T2, ... T19 in cycle and even if we don't
sleep or sleep 1ms it would work. You are right that when scheduler tries to
e
On second thought, the scheduler may be intelligent enough not to start more
than one thread if it knows that they all wait for the same resource. But I
wouldn't assume it.
Well it works for me with 32 characters in the string (Linux, 4 CPUs). So it
seems to depend a bit on the OS - and therefore, the scheduler.
> I think this shouldn't be the case.
I'll try to explain what might happen. I do not know all internals involved, so
it may or may not be accurate.
Supp
> The problem is that threads go to sleep while still holding a lock.
Yes, this was my mistake. Thanks! But anyway after moving sleep to the right
place all still hangs with 6+ characters.
> Well, the real problem is that afaik there is no guarantee that this code
> will ever finish, > because
The problem is that threads _go to sleep while still holding a lock_.
Well, the real problem is that afaik there is no guarantee that this code will
ever finish, because the scheduler is not required to ever wake the right
thread when a bunch of other threads are still waiting. But anyway, Movin
Interesting addition:
I just tested the same in Ubuntu 16.04 under VirtualBox with **2 virtual CPUs**.
And it works for string lengths up to 5.
With strings having 6, 7, 8 ... characters it hangs in 100% of cases.
Interesting.
Can you tell me what happens when proc worker executes "if nCallsCur ==
nCallsTotal: return": Is the lock released for this case. Sorry, no idea.
Playing with threads I found strange behaviour of _spawn_. I made a simple test
of multi-threading: there is the routine
proc multithreadedPrint(sMsg: string, nCount: int)
which prints the specified string _nCount_ number of times. And each character
of the string is printed b
15 matches
Mail list logo
