Showing results for 
Show  only  | Search instead for 
Did you mean: 
Level 2

Dequeuing a queued license request in a multi-license application

Longtime user of FNP-enabled applications here, but total newbie at *developing* them.  Any help appreciated.

Setting the flag argument of lc_checkout() to the non-blocking LM_CO_AVAIL_NOWAIT value allows a Flex-enabled application to queue for a license feature, but continue running the main thread while waiting for a license instance to free up.  lc_status() can be polled to determine when the license instance is acquired.

Consider the case where I want to implement a timeout, giving up on queuing for license feature "A" after a certain amount of time.  I can call lc_free_job() on the job handle associated with feature "A", and/or exit the program when the timeout occurs, and I see a DEQEUE message for feature "A" in the license server log if I do.  So far so good.

But what if I don't want to call lc_free_job() when the timeout expires?  How do I tell the license server to dequeue my queued request while retaining the job?

The scenario I have in mind is a multi-CPU application where the app doesn't start running until it acquires one instance of feature "A", but which will then periodically try to upgrade to obtain additional copies of the license, and if successful, spawn additional processes.  After a certain timeout period, the app would simply continue with one license and one process.  I don't want to call lc_free_job() when the timeout expires, because that will release the original license I'm holding.  But I also don't want the queued request to stay active, because that could result in my application eventually being assigned additional licenses that it won't take advantage of.

I figured there would be something like an lc_dequeue() function to dequeue queued license requests.  But I don't see any such function in the FNP documentation.  Am I just not looking in the right place?  Or is the only viable implementation to assign a separate job to each license feature instance, even though a single job can theoretically manage multiple instances of a feature?

0 Kudos
(0) Replies