[Xapian-discuss] Node.js binding

[Richard Boulton]

On 20 October 2011 21:17, Liam <xapian at networkimprov.net> wrote:
> A mature Node binding would have both sync and async variants of the API,
> and let the user choose based on his knowledge of the deployment context.

Okay; but I don't entirely see what this has to do with whether
Document::get_data() performs IO.

Really, we can't guarantee that any but the most simple API methods
won't block, since that's not part of the Xapian API definitions at
present, and therefore even if they don't block now, we might need to
change them to perform blocking calls in some circumstances future
releases.  Even the Query constructors could block, in theory, since
there's one which takes a user-defined posting source as an argument,
and calls that posting source's "clone()" method, which can do
anything.

>> What I was concerned about was concurrent calls to methods of Xapian
>> objects, which this doesn't avoid.  For example, if the main thread
>> has a "db" variable pointing to a Xapian database, and starts a
>> get_mset() operation, the get_mset() operation will be performed using
>> the Xapian database in a subthread.  From what you describe, there's
>> nothing stopping the main thread kicking off another get_mset()
>> operation (or any other operation which would access the database)
>> before the subthread finishes, which would cause problems.
>
> Concurrent calls to the same method of *different* objects cause problems??

Not usually (though for example, a call to an Enquire object will
often result in a call to a Database object inside Xapian, so this can
be true).

> Node developers already have to deal with the implications of async I/O.
> Simultaneous writes to a file can cause problems. Node avoids
> multi-threading gotchas only in JS code. So yes, a Node developer would know
> to use separate Database instances, or serialize access to a single one.

Okay; then it sounds like the important thing is to document the need
to serialize access to any Xapian objects and objects derived from
them.  I worry that it's a little fragile, and overly easy to cause
concurrent access by mistake, but I don't have enough Node experience
to know whether that worry is valid, so will leave it up to you!

-- 
Richard