thread safty

[uncutstone]

Where to get information about whether a class in ruby standard library
is thread-saft?

For example, is Logger thread safe? Where to find this kind of info?

 

[Robert Klemme]

Where to get information about whether a class in ruby standard library
is thread-saft?

For example, is Logger thread safe? Where to find this kind of info?

IMHO you're safe when assuming that no class is thread safe by itself.
Java went down the road of making collections thread safe by default
(Vector, Hashtable) and they corrected their error later (ArrayList,
HashMap). It's usually a bad idea to make general purpose classes
thread safe because you pay the overhead always even if it's not needed.
Also, for many use cases it's not sufficient to just synchronize
methods. For example, if you check whether a hash contains a certain
key and then act differently depending on whether the key is there or
not you need external synchronization anyway.

Kind regards

robert

 

[uncutstone]

Thanks for the explanation.

 

[uncutstone]

This is discussion about "A tricky problem about Process.wait and popen
" . I post it here because I cannot post it in that thread. Maybe it
is full. I don't know.

Robert Klemme write:

Then place a loop into the thread block.
No, you probably did not understand my code fully: it waits for all
*threads* to terminate! The script creates PARALLEL (i.e. 10) threads
and each of them forks a ruby process and terminates once the child
process has terminated. So you got 10 processes executing in parallel
and the script waits for all to terminate.

Yes , it works and I fully understood your code.

I don't think you need DRb for this. It seems the number of child
processes is an input parameter. You just need to add that to my
script. Then decrement a counter thread safe and have each thread start
a new process as long as you are not done. It's an easy change to the
script I provided earlier.

IMHO, I think DRb has some advantage when there is lots of info to
transfer between processes that's just what I want. The code I listed
earlier was simplified so you cannot see that. By using DRb, the code
is more concise, simpler and easier to understand.

Thanks, it is my pleasure to discuss with you .

 

[Robert Klemme]

This is discussion about "A tricky problem about Process.wait and popen
" . I post it here because I cannot post it in that thread. Maybe it
is full. I don't know.

Um... Since this is a usenet newsgroup I don't think it can ever be
"full". I'm not sure what problems you are experiencing. Maybe they
are related to the fact that you're posting from China.

Robert Klemme write:


Yes , it works and I fully understood your code.

Ok, fine.

IMHO, I think DRb has some advantage when there is lots of info to
transfer between processes that's just what I want. The code I listed
earlier was simplified so you cannot see that. By using DRb, the code
is more concise, simpler and easier to understand.

Ah, I see. Yes in that case the DRb approach is probably better. In
that case I'd still use fork with a block to spawn child processes - the
big advantage is that you do not have to fiddle with path information
(e.g. if "ruby" is not on your path) and you do not have to transfer
information (i.e. DRb port number) via command line arguments. It may
or may not be a disadvantage to have all the code in one script - that
depends; OTOH if it's larger then it's probably reasonable to place
classes in separate files anyway.

Thanks, it is my pleasure to discuss with you .

Ditto.

Kind regards

robert

 

[uncutstone]

Robert Klemme wrote：

Ah, I see. Yes in that case the DRb approach is probably better. In
that case I'd still use fork with a block to spawn child processes - the
big advantage is that you do not have to fiddle with path information
(e.g. if "ruby" is not on your path) and you do not have to transfer
information (i.e. DRb port number) via command line arguments. It may
or may not be a disadvantage to have all the code in one script - that
depends; OTOH if it's larger then it's probably reasonable to place
classes in separate files anyway.

Yes,fork with a block is really better. By using fork, I don't need to
consider the extra path dependency problem, I don't need to transfer
arguments to child process via command line.

But I am sorry that fork is not supported on my out-of-date windows 98
, a 350MHz one. It seems that I have to upgrade my PC now. It gives me
more and more troubles. For example, I cannot install VMWare on windows
98 too.

FYI, below is the result of using fork on my machine:
irb(main):001:0> fork {puts "hello"}
NotImplementedError: The fork() function is unimplemented on this
machine
from (irb):1:in `fork'
from (irb):1

 

[Robert Klemme]

Robert Klemme wrote：


Yes,fork with a block is really better. By using fork, I don't need to
consider the extra path dependency problem, I don't need to transfer
arguments to child process via command line.

But I am sorry that fork is not supported on my out-of-date windows 98
, a 350MHz one. It seems that I have to upgrade my PC now. It gives me
more and more troubles. For example, I cannot install VMWare on windows
98 too.

FYI, below is the result of using fork on my machine:
irb(main):001:0> fork {puts "hello"}
NotImplementedError: The fork() function is unimplemented on this
machine
from (irb):1:in `fork'
from (irb):1

It works on cygwin

09:38:33 [~]: ruby -e 'fork { puts "hello" }'
hello
11:45:50 [~]: uname -a
CYGWIN_NT-5.2-WOW64 PDBXPWSRK38 1.5.19(0.150/4/2) 2006-01-20 13:28 i686
Cygwin


Upgrading is certainly a good idea.

robert