[#113] Re: ruby 1.1d0 released — matz@... (Yukihiro Matsumoto)
Hi.
7 messages
1998/12/16
[#127] very very NEWbie — "Bryce" <crowdog@...>
Ok, I'm having trouble with an extremely simple class.
5 messages
1998/12/20
[#138] Thread Problems — Reimer Behrends <behrends@...>
I have been looking at the thread implementation of Ruby for the past
21 messages
1998/12/23
[#164] Re: Thread Problems
— matz@... (Yukihiro Matsumoto)
1999/01/05
Hi.
[#167] Makefiles and -lcurses
— Klaus.Schilling@...
1999/01/05
Julian Fondren writes:
[#168] Re: Makefiles and -lcurses
— Julian Fondren <julian@...>
1999/01/05
OpenBSD has ncurses and it's own ocurses, and I prefer the latter.
[#169] hah, check these errors
— Julian Fondren <julian@...>
1999/01/05
/usr/lib/libm.so.0.1: Undefined symbol `__GLOBAL_OFFSET_TABLE_' referenced
[#170] Re: hah, check these errors
— matz@... (Yukihiro Matsumoto)
1999/01/05
Hi.
[#171] another question about Makefiles
— Julian Fondren <julian@...>
1999/01/05
Hello,
[#172] Re: another question about Makefiles
— matz@... (Yukihiro Matsumoto)
1999/01/05
Hi.
[#174] some more information
— Julian Fondren <julian@...>
1999/01/06
greetings,
[#175] Re: some more information
— matz@... (Yukihiro Matsumoto)
1999/01/06
Hi.
[#179] Re: some more information
— matz@... (Yukihiro Matsumoto)
1999/01/07
In message "[ruby-talk:00175] Re: some more information"
[#140] ruby 1.3 released — matz@... (Yukihiro Matsumoto)
Hi, all.
10 messages
1998/12/24
[#141] Re: ruby 1.3 released
— Clemens Hintze <c.hintze@...>
1998/12/24
On 24 Dec, Yukihiro Matsumoto wrote:
[#143] Re: ruby 1.3 released
— matz@... (Yukihiro Matsumoto)
1998/12/25
Hi.
[#148] inability to load extension modules in 1.2, core dump
— Julian Fondren <julian@...>
1998/12/27
Ok.. 1.1d9 worked with no problems, and no significant or relevent changes
[#149] Re: inability to load extension modules in 1.2, c ore dump
— Clemens Hintze <c.hintze@...>
1998/12/27
On 27 Dec, Julian Fondren wrote:
[ruby-talk:00138] Thread Problems
From:
Reimer Behrends <behrends@...>
Date:
1998-12-23 04:43:02 UTC
List:
ruby-talk #138
I have been looking at the thread implementation of Ruby for the past
couple of days, and I think I may have found a few problems.
For instance, io.c does a lot of checking to see if a thread can block.
Unfortunately, some of these checks are incomplete. For example, if you run
the following script, the forked thread blocks everything else as soon as
you hit enter until you type Ctrl-D.
-----
fp = open("/dev/tty")
Thread.start do
fp.read
end
while true do
print "Looping.\n"
sleep 2
end
-----
The reason is that there's only one check at the beginning of the
implementation of IO.read whether there is actual data, but no check if
there is sufficient data to satisfy the entire request. Similar problems
result on a number of other occasions, like when reading a locked file,
reading too much data from a pipe, etc.
An obvious solution would be to write custom implementations of read()
and write(), using, for instance, readv() and writev(). This would also
take care of library calls like fread() and fwrite(), except that you
then still end up with sticky reentrancy issues if libc isn't
threadsafe.
There isn't such an issue with sockets, as socket.c is written to make
use of non-blocking semantics.
Comments?
Reimer Behrends
P.S.: Is there a reason why the current implementation is fixed at 10
time slices a second? Most modern computers should be able to
easily handle up to 10 times as much, even if you call select()
each time.