EldoS | Feel safer!

Software components for data protection, secure storage and transfer

Support asynchronous methods in communication API.

Posted: 11/12/2013 05:07:38
by VoxPopuli Robot  (Team)

There should be asynchronous versions of communication methods such as connect/send/receive, so that we don't have to spawn a new thread just to wait for the reply from the server when this can be done more efficiently via overlapped IO etc. Preferrably with cancellationsupport the same way that the various .NET 4.5 Async methods work, e.g. System.Net.Sockets.Socket.ReceiveAsync.

If you like the idea, vote for it on https://www.eldos.com/sbb/wishlist.php
Posted: 01/10/2014 04:29:41
by Peter Palotas (Basic support level)
Joined: 11/01/2012
Posts: 49

As an addition, just to clarify, an Async-method, such as ReadFileAsync, should normally never spawn a new thread (unless required to enable spawning threads for a language/environment that does not natively support it). There are various articles and videos around the net detailing the conventions to adhere to when implementing Async methods.
Posted: 01/10/2014 04:35:01
by Eugene Mayevski (Team)

In SecureBlackbox *Async methods are not implemented but autogenerated. It is not feasible to implement Async method for all classes by hand in a timely manner. IOW that would be not an optimal resource investment.

Sincerely yours
Eugene Mayevski
Posted: 01/10/2014 04:42:18
by Peter Palotas (Basic support level)
Joined: 11/01/2012
Posts: 49

I can see that it is quite difficult do do it for all methods everywhere as things look right now. But there is a performance overhead and some drawbacks to spawning a new thread for each Async-call, so for example Socket-methods do not need to spawn a new thread since they support overlapped I/O. Also, cancellation support can probably only be properly implemented when not spawning threads in this manner. So, just a suggestion.
Posted: 01/10/2014 04:46:05
by Eugene Mayevski (Team)

I understand your point. What I was trying to say is that "proper" implementation of the ideas of Async calls would require rewriting of large parts of code, too large to be justified by possible benefits.

Sincerely yours
Eugene Mayevski
Posted: 07/01/2015 14:19:21
by Paolo Furini (Basic support level)
Joined: 07/01/2015
Posts: 1

I never trust automatic code generation, especially for tricky code like async calls.

For example, are you using Task.Factory.StartNew in all of your wrappers (the simplest overload)?
Take a look at this enlightening article: http://blog.stephencleary.com/2013/08/startnew-is-dangerous.html

If some client code uses your async calls without knowing that you use StartNew, I suppose that you are exposing it to the same threats described in the article..

Just my 2c (PS: I'm not an expert in async code)
Posted: 07/02/2015 07:18:30
by William Egge (Standard support level)
Joined: 08/17/2011
Posts: 37

My thoughts, if you needed ASync "in your code" then you could use a ITask in Delphi XE7, XE8. It wont spawn a new thread unless it has to.
Posted: 07/03/2015 06:28:14
by Ken Ivanov (Team)


Thank you for the reasonable suggestion. Indeed SecureBlackbox uses Task.Factory.StartNew calls to invoke asynchronous calls. We have run some preliminary checks with Task.Run calls instead, and so far they proved to work just fine. So I believe we'll migrate all our asynchronous calls to Task.Run in a foreseeable future.


this is more about the asynchronous model introduced in .NET 4.5. Still, thank you for your suggestion about the methods applicable to Delphi environments, it may be useful to the users of VCL edition too.




Topic viewed 2627 times

Number of guests: 1, registered members: 0, in total hidden: 0


Back to top

As of July 15, 2016 EldoS business operates as a division of /n software, inc. For more information, please read the announcement.

Got it!