On Thu, 3 May 2001, Nicholas Clark wrote:

> On Thu, May 03, 2001 at 06:03:09PM -0400, Dan Sugalski wrote:
> > At 05:54 PM 5/3/2001 -0400, Benjamin Sugars wrote:
> > >On Thu, 3 May 2001, Dan Sugalski wrote:
> > >
> > > > Nope. Callouts to non-reentrant libraries are a Bad Thing...
> > >
> > >I suppose all is not lost if one knows which Perl functions can trigger
> > >such a callout, but that does fly in the face of Sarathy's responsibility
> > >model.
> > 
> > Well, presumably they'll only happen in XS code and the author will take 
> > proper steps to protect the library. (Okay, you can stop laughing now...)
> > 
> > Seriously, there's not a whole lot that perl itself can do about that, 
> > except perhaps single-thread calls to XS routines that aren't guaranteed to 
> > be threadsafe. And that needs to be done across interpreters for IThreads.
> 
> as well as licences, can we add CPAN sections for threadsafeness and
> unicodesafeness, so module authors can declare if they know they have coded
> to cope with them. [I can see a lot of "unknown"s turning up]

Will perl check CPAN every time you compile to see if the module
is thread safe? ;-)

Really, it does help to let the user know, but wouldn't it be
better to be able to declare an XS module to be thread safe in the
Perl program calling it or perhaps in the XS itself? This would
require YAFC (yet another function call), but it would be a way to
control whether or not perl will single-thread the calls.

    use Foo;
    threadsafe Foo;

It's ugly, but it would allow an easy way to let perl know whether
it can safely treat calls to an XS based module as reentrant. It
should default on the paranoid side, of course. I realize I've
just commited the sin of a suggestion without a patch, but the
hard part is single-threading accesses to certain libraries and
allowing reentrant ones to be multithreaded and that was already
mentioned. I'm just suggesting a possible way to tell the difference
in practice.

BTW, if we are talking about things to add to a field in the
brief module description, it really should be whether the module
is a pure Perl moduel, has an XS part, has an Inline part, or
whatever. This way, when someone is searching for a module to
use for part of their project, they don't have to download
each and every module that might work to see if it requires
compilation. Windows people and people with little access to
their web hosting companies would be really thankful, not to
mention those of us who are trying to make our projects portable
to those environments -- I would imagine sometimes people reinvent
a wheel in pure Perl because they are sure the module will need
to be compiled.

Chris

-- 
Disclaimer: Actual product may not resemble picture in ad in any way.

Reply via email to