[zeromq-dev] Delphi OOP Wrapper for ZeroMQ

Martin Sustrik sustrik at fastmq.com
Tue Aug 4 17:17:18 CEST 2009


Great. If there's a way to help you with your presentation feel free to 
ask for it.

Martin

Daniele Teti wrote:
> Good!
> 
> it's nice to see this.
> 
> We are the Italian Embarcadero Representative (Embarcadero is the 
> Company that have bought Delphi from Borland) and in november we'll 
> doing a Delphi Conference (www.itdevcon.it). One of my talk will be on 
> "Messaging System", and I'll talk about ZeroMQ for Delphi programmer. 
> This should be good for ZeroMQ popularity :-)
> 
> regards
> 
> Martin Sustrik wrote:
>> Daniele,
>>
>> Thanks! I've posted the link to your project to the "recent 
>> highlights" section on 0MQ main page.
>>
>> Martin
>>
>> Daniele Teti wrote:
>>> Hi all,
>>>
>>> my Delphi 2009 wrapper for ZeroMQ is available from google code:
>>> */
>>> /*svn checkout 
>>> */http/*://danieletetidemo.googlecode.com/svn/trunk/ZeroMQlib 
>>> danieletetidemo-read-only
>>>
>>> In the example directory there is the Delphi version of the ChatRoom 
>>> example (beta version).
>>>
>>> Have Fun :-)
>>>
>>>
>>>
>>> Pavel Gushcha wrote:
>>>> Can I disable receiving messages from spcecified queue by 
>>>> api_thread_t::receive()?
>>>> Real use case: my application has one api_thread_t, it receives 
>>>> requests, process it and sends responses. While processing request, 
>>>> it sends/receives messages to another applications. I want to 
>>>> implement limit for number of currently processing messages. Easiest 
>>>> implementation for me looks like this: when number of currently 
>>>> processing request goes above limit, i block receiving messages from 
>>>> requests queue. In this case only messages that used in processing 
>>>> will be received, no new request messages.
>>>>
>>>> Now i'm thinking about:
>>>> 1) more complex realization with two api_thread_t, non-blocking 
>>>> receive() and sleep() functions.
>>>> 2) more complex realization with blocking receive() but with two 
>>>> application threads with syncronization between them.
>>>>
>>>> May be threre is more elegant solution for my situation?
>>>>
>>>>
>>>> Thanks for help!
>>>> ------------------------------------------------------------------------ 
>>>>
>>>>
>>>> _______________________________________________
>>>> zeromq-dev mailing list
>>>> zeromq-dev at lists.zeromq.org
>>>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>>>>   
>>>
>>> -- 
>>> Daniele Teti
>>> R&D Director & Educational
>>> bit Time Software
>>> www.bittime.it
>>> www.danieleteti.it
>>> www.codegear.it
>>>
>>>
>>> ------------------------------------------------------------------------
>>>
>>> _______________________________________________
>>> zeromq-dev mailing list
>>> zeromq-dev at lists.zeromq.org
>>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>>
>>
> 
> -- 
> Daniele Teti
> R&D Director & Educational
> bit Time Software
> www.bittime.it
> www.danieleteti.it
> www.codegear.it
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev




More information about the zeromq-dev mailing list