On Fri, 4 May 2001, Artur Bergman wrote:
> 01-05-04 17.31, skrev Benjamin Sugars p� [EMAIL PROTECTED] f�ljande:
>
> > On Fri, 4 May 2001, Alan Burlison wrote:
> >
> >> We might actually be better expending effort in providing a proper event
> >> loop in perl - this is more likely to be achievable within the strictures of
> >> the existing perl5 implementation, and if we are going to end up locking
> >> everything anyway, it may not end up being any slower.
> >
> > Agreed. There are many other things with a higher utility/work ratio.
> >
> > This is not meant to denigrate the hard work that Artur is doing. I just
> > don't see ever being able to access any more than a subset of Perl from
> > threaded perl. I hope I'm wrong.
> >
> > Cheers,
> > -Ben
>
> Even if so, I might be happy to use that subset of Perl in a threaded
> enviroment. Frankly I don't write code that deals alot with the system
> information, mostly my work is in IO and dealing with datastreams. I would
> be happy if this subset worked properly in threaded mode. I am going to try
> and get this to work for the subset of Perl I am using, I think that a group
> of people working in the same problem domain as I do will have uses of this
> threading.
Considering that the major win which comes with threading is more
speed and that most of the time in a program is spent waiting for
I/O events, it would be of great value to be able to do file, pipe,
and socket I/O from within threads even if most system calls wouldn't
work.
An even better idea is to tell the user to make sure all the
non-threadsafe work gets done in the same thread, and that the
other threads be allowed to do whatever they can with the subset
which is thread-safe. Perhaps we could make sure that when someone
creates new threads, the original main thread cannot creat a new
thread which will do non-threadsafe calls of Perl builtins, and
that any outside libraries (XS modules, etc.) be declared thread-safe
by the user before the user can put calls to the library functions
in the subset-only threads.
This is nothing but a workaround, but it's better than not having
threads.
Chris
--
Programming is a tool. A tool is neither good nor evil. It is
the user who determines how it is used and to what ends.
