Hi Noel
> I have a question about queries with JPL.
>
> This is the kind of thing I am trying to :
> I want several concurrent "things" doing queries to prolog, and
> retrieving the solution in the order (I mean the order between
> different queries, not the solution of one query) they want.
Yes you can do this with JPL
> For example two "things" t1 and t2 create each a query q1 and q2,
> and t1 get the first solution of q1, then t2 get two solutions for
> q2, and t1 then get a solution for q1, then t2 close q2, then t1
> get another solution of q1.
>
> So this is a classical concurrent use of prolog.
>
> What I am doing to "implement" this is to have an actor (an actor
> is a mailbox that can receive and send to other actors, anb that
> cab be thread based, but also event based, using available threads
> when it needs to do something ...) that do the query to the prolog
> engine, and the "things" are threads or actor or whatyouwant that
> create an object query that send a message to the prolog actor and
> get the result.
>
> So it is transparent for the "things", they just use a Query
> object, and the query object does the job of asking to the actor
> (what is good with actor is that I don't have to think about
> concurrence, since they are treating messages sequentially)
>
> And my problem is that sometimes I get exceptions like that :
> jpl.JPLException: this Query (9004539:logtalk_load(
> '.'(negociation(seller), []), [] )) is not topmost
> (8814217:logtalk_load( '.'(negociation(buyer), []), [] )) within
> its engine[-1254103840]
>
>
> I think there is something bad with my design and threads, but
> since I don't know how are things working inside JPL, I can't
> solve it by myself.
OK, your program has got its knickers in a twist :-)
JPL is just a library, interfacing SWI-Prolog's public FLI to a
JVM's public JNI. Understanding the FLI is a good basis for
understanding JPL and its exceptions. I believe the following
is true of FLI and JPL.
You can have several engines, but at most one per thread. If you
open a query in an engine while another query is still open there,
the new query is stacked on top of the previous one. You must
exhaust or otherwise close the new before trying to get a further
solution from the old. If you break this rule, JPL throws an
exception just like the above (I forget what FLI does).
So for each new query you must decide, are you happy to stack it
on an existing query or must it have its own engine (hence its
own thread).
For independent, concurrent queries you should easily be able to
wrap jpl.Query in a new class which runs it in a private thread?
> If someone have a better idea to make these queries ...
>
> A note about actors : if they are thread based my design was
> working at a time, but if they are event based, then they use a
> thread available in a thread pool and then it seems to make a
> problem with JPL ...
That encourages me to believe that you are just reusing engines
inappropriately. JPL maintains its own engine pool, returning
an engine when a thread's (bottom-most) query is closed, so I
can't see any need for (or benefit from) another pool: try
creating concurrent queries as suggested.
How many queries might you need open concurrently? JPL arbitrarily
limits you to 10 in jpl.c
#define JPL_MAX_POOL_ENGINES 10 /* max pooled Prolog engines */
#define JPL_INITIAL_POOL_ENGINES 1 /* initially created ones */
> Thanks you for any help :)
>
> Victor
regards
Paul Singleton
_______________________________________________
SWI-Prolog mailing list
SWI-Prolog@...
https://mailbox.iai.uni-bonn.de/mailman/listinfo.cgi/swi-prolog
signature.asc (196 bytes) 